Calling Amazon Bedrock from application code: DVA-C03 study notes and practice questions

What to know for the exam

Bedrock questions describe an application that calls a model, and ask which API, option or retry pattern meets a requirement. You are not expected to choose a model or write prompts. Focus on the call, the streaming, the limits and the access controls.

Choosing the API

• Converse and ConverseStream use one request shape for every Bedrock model that supports messages, and return one normalized response with the output, stop reason and token usage. Use them by default, so switching models needs little code change.
• InvokeModel and InvokeModelWithResponseStream send the model’s own request body. Use them when a model needs a feature the Converse format doesn’t expose. The body is a JSON string or bytes in the model’s own format, not a language-native object, and the response body is a stream that your code reads and decodes before parsing.
• Streaming returns text as it is generated, which suits chat interfaces. Streaming support varies by model.
• Prompt caching stores a long, repeated prompt prefix, such as a fixed system prompt, so later requests read it at a lower rate. Place the cache checkpoint after the static content.
• Step Functions has an optimized Bedrock InvokeModel task, so a workflow calls a model without a Lambda function. Its Body field takes up to 256 KiB; for larger requests, the Input field points to an S3 object instead.

Tool use

• You describe tools in the request (toolConfig in Converse). The model responds with a toolUse block and a stop reason of tool_use, naming a tool and its input.
• Your code runs the tool and sends a toolResult block with the same toolUseId in the next user message. The loop continues until the model returns a final answer.
• Your application, not the model, runs the tool, so check permissions in your code.

Throttling and retries

• When a quota is exceeded, Bedrock returns ThrottlingException. Retry with exponential backoff and jitter. The AWS SDKs retry throttling errors automatically, and you can configure more attempts.
• For steady, predictable load, buy provisioned throughput. For spiky load, on-demand quotas can be the bottleneck.
• Cross-Region inference profiles route requests across Regions to absorb spikes. The call uses the profile’s ID, often with a us. or eu. prefix.
• Application inference profiles add tags so costs can be tracked per team or feature.

Batch inference

• For large jobs where answers are not needed right away, use batch inference. You put input in Amazon S3 and read the output from S3 when the job finishes. It costs less than real-time calls.

Calling an AgentCore Runtime agent

• Amazon Bedrock AgentCore Runtime hosts an agent. Your application calls the agent’s runtime endpoint with the AWS SDK, (InvokeAgentRuntime), using IAM credentials or the configured inbound authentication. Pass a unique runtimeSessionId (at least 33 characters) per conversation: each session runs in its own microVM, and reusing the ID keeps the conversation’s context. A session stops after 15 minutes idle or 8 hours by default, and its in-memory state is lost, so use AgentCore Memory for history that must outlast the session.

How to choose

Common traps

• Batch inference for a live user request.
• Ignoring throttling instead of retrying with backoff.
• Giving the application’s code broad bedrock:* rights. Grant only the invoke actions it needs.
• Forgetting that tool execution happens in your code.
• Retrying throttled calls with no delay, or with a fixed sleep that sends retries together.
• Reusing one session ID for every user of an AgentCore agent.

Try the 1 practice question ↓