When using Bedrock Converse API, how do you handle streaming responses?
ConverseStream is the Bedrock Converse API operation that returns incremental response chunks over an event stream. Selecting it satisfies the stem's streaming requirement, whereas the non-streaming Converse call returns the complete response only after generation finishes.
Why this answer
The Bedrock Converse API provides a dedicated streaming operation called ConverseStream, which returns a stream of events (e.g., messageStart, contentBlockDelta, messageStop) as the model generates tokens. This is the correct way to handle streaming with the Converse API because it is purpose-built for the unified conversational interface, supporting multi-turn chat and tool use. Unlike InvokeModelWithResponseStream (used with the InvokeModel API), ConverseStream maintains the Converse API's message format and event structure.
Exam trap
AIP-C01 often tests the distinction between the InvokeModel API and the Converse API, tricking candidates into selecting InvokeModelWithResponseStream (or a misspelled variant like InvokeModelStream) when the question specifically asks about the Converse API's streaming operation.
How to eliminate wrong answers
Option A is wrong because InvokeModelStream is not a real Bedrock API operation; the actual streaming operation for the InvokeModel API is InvokeModelWithResponseStream, and it does not use the Converse API's message format. Option B is wrong because polling the API until finished is a non-streaming, synchronous pattern that defeats the purpose of streaming and is not how Bedrock supports real-time token delivery. Option C is wrong because Bedrock does not support callback URLs for streaming responses; streaming is handled via direct HTTP/2 or event stream connections, not webhooks.