Exams / AIP-C01 / Study guide / Formatting and enriching input for model requests (Converse API, Comprehend, normalization)
Formatting and enriching input for model requests (Converse API, Comprehend, normalization): AIP-C01 study notes and practice questions
What to know about Formatting and enriching input for model requests (Converse API, Comprehend, normalization) for the AIP-C01 exam, from the Foundation Model Integration, Data Management, and Compliance domain (31% of the exam guide), then 1 free question to test it. Part of the AIP-C01 study guide.
AIP-C01 tests where a transformation belongs and whether the request follows the API’s structure. Wrong options either send raw, messy input or put instructions in the wrong part of the request.
Converse API structure
system is a separate field, not a message. Put instructions, persona and rules there.
messages is an ordered list of turns. Each turn has a role (user or assistant) and content blocks such as text, image, document, tool use or tool result. Tool results return as content in a user turn.
For a dialog application, send prior turns as messages in order, trimmed to fit the context window. Keep the full history in a store such as DynamoDB or AgentCore Memory, and send the trimmed version.
Use ConverseStream when the user should see tokens as they arrive.
Amazon Comprehend detects entities, key phrases, sentiment and PII. Use PII detection to redact personal data before text reaches a prompt or a log. Use entity extraction to add structured context the prompt can use.
Enrichment output becomes labeled context in the request, which reduces ambiguity for the model.
Normalize with deterministic code
Messy input such as dates in several formats, mixed units, currencies or misspellings should be normalized by Lambda code before prompting. Code is exact, cheap and testable. Use a foundation model to reformat free text only when rules cannot cover it, and validate its output.
Payload shapes
Bedrock requests use the Converse shape or a model-specific InvokeModel body. A SageMaker AI real-time endpoint accepts whatever payload its container expects, often JSON with a fixed schema, so the client must send that exact structure. Keep request building in one module so that changing the endpoint or model does not spread edits across the application.
How to choose
Scenario wording
Choose
“Dialog app must remember earlier turns”
Ordered prior messages, trimmed to the window
“Persona and rules apply to every turn”
The system field
“Redact names before logging or prompting”
Comprehend PII detection
“Partners send dates in five formats”
Lambda normalization
“One request shape across Bedrock models”
Converse API
“Custom container on a real-time endpoint”
The JSON payload the container defines
Common traps
Putting instructions in a user message instead of the system field.
Sending the entire unbounded history and exceeding the context window.
Using a foundation model for date normalization that code can do exactly.
Assuming one body works across Bedrock models and SageMaker AI endpoints.
Enriching after the prompt is built, so the model never sees the extracted entities.
An HR software company adds a policy assistant to its platform. The assistant must follow fixed behavior rules, such as never giving legal advice, and those rules must not be changed by text that users type.
The company supports two model families from different providers, and it wants one request format for both so that it can switch models without rewriting the code. Earlier prototypes mixed the rules, the earlier chat turns and the new question into one long user message, and users could sometimes override the rules.
The chat history must still reach the model in the order the conversation happened.
Which request structure meets these requirements?
Choose one answer.
AA. Join the rules, the earlier turns and the new question into one user message in each request, so that the model receives all of the context in a single turn.
BB. Put the rules in the system field of a Converse request and the history and new question as alternating user and assistant messages, for both model families.
CC. Insert the rules as an assistant message at the start of every request, so the model treats them as commitments it made earlier and keeps following them throughout the chat.
DD. Use InvokeModel for each family with its own model-specific body, placing the rules in the system field each model expects, so that every model receives its native request format.
Show the answer and explanation
Answer: B
A. Wrong: Mixing rules and user text in one message lets the user's text compete with the rules, which is the override problem. It also loses the turn structure that the model uses to follow the conversation.
B. Right: The Converse API keeps the system instructions separate from user turns and accepts one request shape across supported models, so switching models needs no code rewrite. Alternating messages preserve the conversation order, which meets every requirement. Learn more: Carry out a conversation with the Converse API (opens in a new tab)
C. Wrong: Rules placed in an assistant turn are not a reliable system instruction, and users can still write text that overrides them. This structure misuses the message roles and does not give the protection the company needs.
The Converse API separates the system instructions from user turns and uses one request shape across models, which makes model switching a configuration change. Alternating user and assistant messages keep the history in order. Mixing everything into a user message, misusing the assistant role and maintaining per-family bodies each fail a stated requirement.
Want more on Formatting and enriching input for model requests (Converse API, Comprehend, normalization)? The 5 full-length practice sets have 5 more Formatting and enriching input for model requests (Converse API, Comprehend, normalization) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Formatting and enriching input for model requests (Converse API, Comprehend, normalization)