Implementation and Integration of Generative AI Solutions — AWS Certified Generative AI Developer AIP-C01 practice questions

An application uses Bedrock Guardrails, and a user's request triggers content filtering, causing the model response to be blocked mid-generation. The application currently just displays a generic '500 Internal Server Error' to the user. What is the BEST way to improve this handling?

1. Log the event and take no user-facing action, since guardrail interventions are rare
2. Detect the specific guardrail intervention reason in the response and show the user a clear, non-alarming message explaining the request could not be completed as asked
3. Automatically retry the exact same request against the same guardrail configuration up to five times
4. Disable the guardrail for that user's session so future requests are not blocked

Answer: B — Detect the specific guardrail intervention reason in the response and show the user a clear, non-alarming message explaining the request could not be completed as asked

A content-filtered response is an expected, identifiable outcome, not a server failure, so the application should distinguish it from real errors and communicate clearly to the user rather than showing a generic 500, which implies a system bug rather than an intentional policy action. Retrying the identical request against an unchanged guardrail configuration will trigger the same filtering outcome again and wastes invocations without resolving anything. Disabling guardrails to work around a block undermines the safety control the application deliberately put in place and is not an appropriate application-layer fix. Silently doing nothing leaves the user confused by a broken-looking response and misses a legitimate opportunity to explain what happened, which matters for usability even if such events are infrequent.

A financial services company runs a customer-facing assistant on Bedrock with consistently high, predictable request volume around the clock, and the business requires guaranteed throughput with no risk of on-demand throttling during peak hours. What is the MOST appropriate Bedrock capacity model for this workload?

1. On-demand invocation combined with a higher service quota request submitted once, permanently eliminating throttling risk
2. Provisioned Throughput purchased with no term commitment, billed strictly per token processed
3. Provisioned Throughput, purchased for a committed term to reserve dedicated model capacity
4. On-demand invocation, since it automatically scales to unlimited throughput for any workload

Answer: C — Provisioned Throughput, purchased for a committed term to reserve dedicated model capacity

Provisioned Throughput reserves dedicated model capacity for a committed time period, which is exactly what guarantees consistent throughput without exposure to on-demand throttling for sustained, predictable, high-volume workloads. On-demand invocation is shared capacity subject to account-level throttling limits; it is not truly unlimited, so it cannot guarantee throughput the way the business requires. A higher quota reduces the chance of throttling but is still a shared, best-effort limit rather than dedicated reserved capacity, so it does not eliminate throttling risk. Provisioned Throughput is purchased as a term commitment (for example, hourly commitments over a period), it is not offered as a no-commitment, purely per-token billing model, that pricing structure describes on-demand, not Provisioned Throughput.

An application uses Amazon Titan Image Generator to create a promotional image from a user's prompt. The Bedrock response returns the generated image as base64-encoded data within the JSON response body. What is the NEXT step the application must perform before it can display the image to the user in a browser?

1. Store the base64 string unmodified in the database and treat it as the final display-ready artifact with no decoding required
2. Decode the base64 string back into binary image bytes and either render it as a data URI or save it and serve it from a URL
3. Pass the base64 string directly into an <img> tag's src attribute with no further processing, since browsers render raw base64 natively
4. Re-invoke the model with InvokeModelWithResponseStream to receive the same image progressively

Answer: B — Decode the base64 string back into binary image bytes and either render it as a data URI or save it and serve it from a URL

Base64-encoded image bytes must be decoded back into binary before they are usable as an image, then either embedded as a properly formatted data URI (with the correct MIME type prefix) or written to storage and served via URL, that decode-and-render step is the necessary next action. Simply dropping the raw base64 string into an <img> src without the required 'data:image/...;base64,' prefix and proper formatting will not render correctly, a bare base64 string is not itself a valid image URI. Re-invoking with the streaming API is for token-by-token text generation UX and is not how image generation responses are delivered or re-fetched. Storing the base64 string unmodified is a legitimate persistence choice, but it does not by itself make the data display-ready, decoding/formatting is still required whenever it's actually rendered.

An agent has two action groups — one for querying inventory and one for processing refunds — plus a knowledge base of return-policy documents. Users sometimes ask questions that don't require any tool at all, such as 'what are your store hours?' What determines whether the agent invokes a tool, queries the knowledge base, or answers directly from the model's own instructions?

1. The agent always queries the knowledge base first, then falls back to an action group only if no relevant passages are found
2. The agent's orchestration step, guided by its instructions and the descriptions attached to each action and knowledge base, reasons about which resource (if any) is needed for the specific user input
3. The developer must write a separate intent-classification Lambda function that routes every message before the agent sees it
4. The order in which action groups were added to the agent determines which one is checked first for every request

Answer: B — The agent's orchestration step, guided by its instructions and the descriptions attached to each action and knowledge base, reasons about which resource (if any) is needed for the specific user input

Routing among tools, retrieval, and direct response is handled by the orchestration model itself during each turn, using the natural-language descriptions of the action groups and knowledge base together with the agent's instructions to decide what's actually needed for that input — a store-hours question needs neither tool. Building a separate classifier Lambda duplicates work the orchestration model already performs and isn't how Bedrock Agents route by default. Action groups aren't evaluated in a fixed registration order; the model considers relevance per turn, not by list position. There's no fixed 'always try the knowledge base first' rule; the agent decides per query which resource, if any, applies.

A customer-facing chatbot frequently receives near-duplicate questions (e.g., many phrasings of 'what are your return hours') that all require the same underlying model-generated answer. Latency and Bedrock invocation costs are both concerns. Which enhancement addresses BOTH without materially harming answer freshness for genuinely new questions?

1. Introduce a semantic caching layer that matches incoming queries against previously answered, semantically similar queries and reuses the cached response when the similarity exceeds a threshold
2. Increase the model's max token output so future answers are more complete on the first try
3. Switch the underlying model to a larger, more capable model to reduce the chance of a wrong answer
4. Reduce the model's temperature to 0 for every request to make responses more deterministic

Answer: A — Introduce a semantic caching layer that matches incoming queries against previously answered, semantically similar queries and reuses the cached response when the similarity exceeds a threshold

A semantic cache recognizes that differently worded questions carry the same intent and serves the previously generated answer for high-similarity matches, cutting both latency and repeated invocation cost while still calling the model fresh for genuinely novel queries. Increasing max tokens affects response length/completeness, not repeated cost or latency for duplicate questions. A larger model could improve quality but would increase, not decrease, per-invocation cost and latency, the opposite of what's needed here. Setting temperature to 0 improves consistency of a single model call but does nothing to avoid re-invoking the model for repeated semantically similar questions.

A team has thoroughly tested a Bedrock agent using the 'DRAFT' working version and is ready to expose it to production traffic through their application, while still being able to iterate on further changes without disrupting live users. What is the recommended approach?

1. Duplicate the entire agent configuration into a brand-new agent resource named for production use
2. Increase the DRAFT version's provisioned throughput so it can handle production traffic
3. Create a numbered agent version from the tested DRAFT, then point a production alias at that version
4. Rename the DRAFT version to 'production' and route the application directly to it

Answer: C — Create a numbered agent version from the tested DRAFT, then point a production alias at that version

The supported pattern is to snapshot the tested DRAFT into an immutable numbered version and route production traffic through an alias pointed at that version, which keeps DRAFT free for continued iteration without affecting live users. The DRAFT version is mutable by design and keeps changing as the team edits the agent, so routing production directly to it means any future edit immediately affects live traffic. Duplicating into a whole separate agent resource creates unnecessary operational overhead (two agents to keep in sync) when versions and aliases exist specifically to avoid that. Provisioned throughput is a model-invocation capacity setting; it has no bearing on separating a stable production configuration from an actively edited draft.

A platform team wants to serve dozens of small, similarly structured fine-tuned models cost-effectively on SageMaker, without provisioning a dedicated endpoint (and its associated fixed cost) for every individual model, while accepting that infrequently used models may incur a brief load time on first invocation after being evicted from memory. Which SageMaker capability BEST matches this requirement?

1. A separate real-time endpoint per model, load balanced by an Application Load Balancer
2. A single serverless inference endpoint configured to hold all models permanently resident in memory
3. SageMaker batch transform, run continuously in a loop across all models
4. A multi-model endpoint, which dynamically loads and unloads models from a shared fleet of instances behind a single endpoint

Answer: D — A multi-model endpoint, which dynamically loads and unloads models from a shared fleet of instances behind a single endpoint

Multi-model endpoints let many models share a common instance fleet behind one endpoint, dynamically loading a model on first use and evicting less-used ones, which delivers the cost efficiency of shared infrastructure at the tradeoff of an occasional load-time delay, matching every constraint in the scenario. Standing up a dedicated endpoint per model reintroduces exactly the fixed per-model cost the team is trying to avoid, multiplied across dozens of models. Serverless inference endpoints don't offer a mechanism to permanently keep an arbitrary set of distinct models resident together behind one endpoint, that description doesn't match how the service works. Running batch transform continuously in a loop is not a serving pattern for on-demand, low-latency individual predictions, it's an offline, bulk processing tool.

A GenAI document pipeline uses SQS to buffer incoming processing requests, and a Lambda consumer invokes Bedrock for each message. Occasionally, a message is processed successfully but the acknowledgment (delete) fails, causing SQS to redeliver the same message and the document to be summarized twice. What is the BEST design change to prevent duplicate processing side effects?

1. Make the processing step idempotent, for example by checking a persisted record of already-processed message IDs before invoking the model again
2. Reduce the SQS visibility timeout to as close to zero as possible so redelivery happens faster
3. Switch from SQS standard queues to SNS topics for message delivery
4. Increase the Lambda function's reserved concurrency to prevent duplicate deliveries

Answer: A — Make the processing step idempotent, for example by checking a persisted record of already-processed message IDs before invoking the model again

SQS standard queues provide at-least-once delivery by design, so duplicate deliveries are an expected possibility, not a bug, and the correct mitigation is to make the consuming logic idempotent (for example, tracking processed message IDs) so redelivery doesn't cause duplicate side effects. Shrinking the visibility timeout makes redelivery happen sooner and more often, worsening the duplicate-processing risk rather than fixing it. SNS is a pub/sub notification service, not a queuing replacement here, and switching to it doesn't change the at-least-once delivery semantics or eliminate duplicates. Reserved concurrency controls how many Lambda instances can run in parallel; it has no effect on whether SQS redelivers an individual message after an acknowledgment failure.

A chat application wants to display the model's answer progressively, word by word, as it is generated, rather than waiting for the complete response before showing anything. Which Bedrock API operation supports this behavior?

1. InvokeModel, which returns the full completion only after generation finishes
2. GetFoundationModel, which retrieves metadata about a specified model
3. ListFoundationModels, which enumerates the models available to the account
4. InvokeModelWithResponseStream, which returns the model's output as a series of incremental chunks

Answer: D — InvokeModelWithResponseStream, which returns the model's output as a series of incremental chunks

InvokeModelWithResponseStream is the streaming variant of Bedrock's invocation API, returning the response as a sequence of incremental chunks that the application can render as they arrive, exactly the progressive-display behavior described. Plain InvokeModel is a synchronous call that returns the complete response only once generation is fully finished, which is the opposite of the desired incremental rendering. GetFoundationModel returns descriptive metadata about a model (such as its capabilities and provider), it has nothing to do with invoking the model or streaming output. ListFoundationModels is a discovery API for enumerating available models in the account/region; it does not invoke a model or return generated content at all.

A developer configuring a Bedrock agent action group has only three simple parameters (a customer ID, a date range, and a status filter) with no need for nested objects or multiple HTTP methods. Compared to authoring a full OpenAPI schema, what is the advantage of instead defining the action using the function-detail schema format?

1. It is the only format Bedrock supports for actions backed by a Lambda function
2. It automatically generates API Gateway routes for the underlying Lambda function
3. It removes the need to grant the agent's execution role permission to invoke the Lambda function
4. It lets the developer declare the function's name, description, and parameters directly and concisely, without writing a full OpenAPI document

Answer: D — It lets the developer declare the function's name, description, and parameters directly and concisely, without writing a full OpenAPI document

The function-detail schema is a lighter-weight alternative meant for simple, flat parameter sets, letting a developer skip the overhead of a full OpenAPI document when there's no real need for one. Both OpenAPI schemas and function-detail schemas can back Lambda-backed actions, so OpenAPI is not excluded, it's just heavier than necessary for a simple case. Neither schema format provisions API Gateway resources; that would need to be set up separately if desired. Invocation permissions are an IAM concern independent of which schema format describes the action's parameters.

What is a typical serverless architecture pattern for a GenAI application on AWS?

Amazon API Gateway receives client requests, AWS Lambda handles request processing and business logic, and Lambda invokes Amazon Bedrock for inference, avoiding the need to manage any servers.

What is response streaming in the context of Bedrock model invocation?

An API mode (e.g., InvokeModelWithResponseStream) where generated tokens are returned incrementally as they are produced rather than waiting for the full response, reducing perceived latency in interactive applications.

What is an Amazon Bedrock Agent?

A managed capability that lets a foundation model orchestrate multi-step tasks by reasoning about user requests, invoking APIs or business logic through action groups, and optionally retrieving knowledge from a knowledge base.

What defines a multi-modal foundation model?

A model capable of accepting and/or generating more than one content type—such as text, images, audio, or video—within a single inference call, for example describing an image or answering questions about visual content.