AWS Certified Generative AI Developer – Professional
Prompt caching on Amazon Bedrock explained for AIP-C01 Prompt caching lets Bedrock reuse a prompt prefix that repeats across requests, which lowers input token cost and latency. With explicit caching you place cache checkpoints after static content, and any change before a checkpoint causes a cache miss. With caching on, inputTokens counts only uncached tokens.
How it works Implicit caching reuses eligible prefixes automatically and is best effort. Explicit caching uses checkpoints that mark the prefix to cache. With the Converse and ConverseStream APIs, you put cache checkpoints in the prompt.
The cached prefix must stay identical between requests. Example: a system prompt that starts with a claim ID and a timestamp, followed by 12,000 tokens of fixed guidelines, misses every time. Move the claim ID and timestamp to the user message and put the checkpoint after the guidelines.
Each checkpoint needs a minimum number of tokens in the whole prefix before it, from 512 to 4,096 depending on the model. A checkpoint below the minimum still lets the request succeed, but nothing is cached.
TTL The cache has a TTL that resets on each cache hit. Many models support 5 minutes, and some also support 1 hour. AWS suggests the 1-hour cache when a prompt is reused less often than every 5 minutes but more often than every hour, such as a chat where the user may not reply within 5 minutes.
You can mix TTLs in one request, but entries with a longer TTL must come before shorter ones. So if the checkpoint after the conversation history uses 1 hour, the earlier checkpoint after the system prompt must use 1 hour too.
Tokens, billing and quota Tokens read from the cache are billed at the cache-read rate. Tokens written to the cache can be billed above the standard input rate, depending on the model. Cache reads don't count toward your TPM quota. Cache writes do.
With caching on, inputTokens is only the non-cached tokens. Total input tokens = inputTokens + cacheReadInputTokens + cacheWriteInputTokens. A per-tenant bill that sums only inputTokens undercounts.
Where the exam catches people Believing a checkpoint helps when the prefix holds a per-request value: any change before the checkpoint causes a cache miss. Believing you can set 1 hour on a later checkpoint and keep 5 minutes on an earlier one: longer TTL entries must come first. Believing inputTokens is the full input count with caching on: add cacheReadInputTokens and cacheWriteInputTokens. Believing moving static content to the end of the prompt helps caching: the cache reuses a prefix, so static content goes first. Believing cache reads use up TPM quota: they don't count toward it, which is why caching can also reduce throttling. Written from Amazon Web Services's documentation Try 3 questions on this Pick an answer to see why each option is right or wrong.
A publishing company summarizes about 30,000 articles each night with an Anthropic Claude model on Amazon Bedrock. An AWS Lambda function calls the Converse API once for each article. Every request starts with the same 9,000-token style guide in the system prompt, followed by the article in the user message. The summaries must be ready by 07:00, and the job currently finishes by 02:00.
Input token costs are high because the model processes the style guide again for every article. The company wants later requests to read the style guide from a prompt cache. The company must keep the same model and the same summary format.
Which solution will meet these requirements? Right. In the game that’s Renown for your Operational Efficiency and Optimization for GenAI Applications building.
Not that one: B is right. In the game your Operational Efficiency and Optimization for GenAI Applications building would lose a little Renown, and this question would come back later.
Your answer A. Store the style guide in an Amazon Bedrock knowledge base. Have the Lambda function call the RetrieveAndGenerate API for each article with the passages that match it.A knowledge base sends only matching passages of the guide, which is retrieval rather than caching and can change the summary format. The answer B. Keep the Converse calls from the Lambda function and the current prompt order. Add a cache checkpoint after the style guide in each system prompt.Explicit prompt caching on the Converse API reuses a static prefix across requests. Your answer C. Write the articles to JSONL files in Amazon S3 with a cache checkpoint after the style guide in each record. Run a nightly batch inference job for the model.Batch looks like the natural home for a nightly job, but caching only works on on-demand calls, so the guide is processed in full every time. Your answer D. Keep the Converse calls from the Lambda function. Move the style guide to the end of the user message after the article, and add a cache checkpoint after it.With the article first, the prompt prefix before the checkpoint changes on every request, so every request misses the cache.
Show the full explanation and doc quotes The prompt caching page states that for the Converse and ConverseStream APIs, "For Explicit Prompt Caching, specify cache checkpoints in your prompts." The style guide is the same at the start of every request, and 30,000 requests over a few hours keep the cache in use.
Written from docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html
A company runs a research assistant that calls Claude Sonnet 4.5 on Amazon Bedrock through the Converse API. Each request starts with a 12,000-token system prompt that is the same for every user, followed by the user's conversation history. Requests from all users arrive several times each minute. One cache checkpoint follows the system prompt and a second follows the conversation history, both with the default TTL.
Users often read sources for 10 to 30 minutes before they send the next message, and that request misses the cache for the conversation history. The history must be read from the cache when a user returns within an hour.
Which solution will meet these requirements? Right. In the game that’s Renown for your Operational Efficiency and Optimization for GenAI Applications building.
Not that one: A is right. In the game your Operational Efficiency and Optimization for GenAI Applications building would lose a little Renown, and this question would come back later.
The answer A. Set ttl to 1h in the cachePoint that follows the conversation history. Also set ttl to 1h in the cachePoint that follows the system prompt in each request.The TTL order inside a request decides it. The prompt caching page says "You can use both 1-hour and 5-minute cache controls in the same request, but with an important constraint: Cache entries with longer TTL must appear before shorter TTLs (i.e., a 1-hour cache entry must appear before any 5-minute cache entries)." The system prompt comes first in every request, so once the conversation checkpoint uses 1 hour, the system prompt checkpoint must too. The same page lists the case: "storing a long chat conversation with a user and you generally expect that user may not respond in the next 5 minutes." Your answer B. Keep the default TTL in both cachePoint objects. Store each conversation in Amazon DynamoDB, and send a short summary instead of the full history with each request.This avoids the cache problem by sending something else. The requirement is that the history itself is read from cache. Your answer C. Set ttl to 1h in the cachePoint that follows the system prompt. Keep the default TTL in the cachePoint that follows the conversation history in each request.The conversation history keeps the 5-minute TTL, so a user who returns after 10 to 30 minutes still misses the cache. Your answer D. Set ttl to 1h in the cachePoint that follows the conversation history. Keep the default TTL in the cachePoint that follows the system prompt, which traffic from other users keeps refreshed.The system prompt entry would keep the 5-minute TTL and sit before the 1-hour conversation entry, which breaks the rule that longer TTLs must come first.
A software company offers a multi-tenant document assistant that calls the Amazon Bedrock Converse API. The company bills each tenant for the input tokens that the tenant's requests send. The application stores the usage object of every response with the tenant ID, and a nightly job adds up the inputTokens values for each tenant.
Last month, the company added a cache checkpoint after a long system prompt that all tenants share. From now on, the bill must count every input token that each request sends and must show cached tokens on separate lines, because they are charged at different rates.
Which solution will meet these requirements? Right. In the game that’s Renown for your Operational Efficiency and Optimization for GenAI Applications building.
Not that one: C is right. In the game your Operational Efficiency and Optimization for GenAI Applications building would lose a little Renown, and this question would come back later.
Your answer A. Keep the sum of the inputTokens values as the billed total for each tenant. Show the cacheReadInputTokens and cacheWriteInputTokens values from each response as separate lines that break down that total.inputTokens excludes every token read from or written to the cache, so the billed total misses the cached share of each request and the cache lines are not a breakdown of it. Your answer B. Call the CountTokens API with each request body before the request is sent, and bill the returned count as the total for each tenant. Show that count next to the inputTokens value from each response.CountTokens returns a count before inference, so it cannot say which tokens were read from or written to the cache, and the bill cannot show them on separate lines. The answer C. Bill the sum of the inputTokens, cacheReadInputTokens, and cacheWriteInputTokens values from each response as the total for each tenant. Show the two cache values as separate lines.The prompt caching page states: "When prompt caching is enabled, the inputTokens field represents only the non-cached input tokens (tokens that were not read from or written to the cache)." Your answer D. Bill the sum of the inputTokens and cacheWriteInputTokens values from each response as the total for each tenant. Show the cacheWriteInputTokens value as a separate line, and leave cache reads off the bill.Cache writes plus uncached tokens is the right sum for sizing throughput in some cases, but a bill for every token sent needs the cache reads too.
Show the full explanation and doc quotes It then gives the formula "total input tokens = inputTokens + cacheReadInputTokens + cacheWriteInputTokens". Summing all three per response restores the full count, and the two cache fields are already the separate lines the bill needs.
Written from docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html
Related Certopolis is an independent study game. It is not affiliated with, endorsed by or sponsored by Amazon Web Services, and its questions are not the exams' questions. Exam names are trademarks of their owners.