Free AIP-C01 Practice Test Questions 2026

B.   Use Amazon Bedrock Data Automation (BDA) with foundation models (FMs) to process document files. Integrate BDA with Amazon Textract for PDF extraction and with Amazon Transcribe for multimedia files. Store the processed content in Amazon S3 with versioning enabled. Store the metadata in Amazon DynamoDB. Collaborate in real time by using AWS AppSync GraphQL subscriptions and DynamoDB.

Explanation:

The system must handle large-scale ingestion (10,000+ sources/day, 500 concurrent uploads), extract structured insights from both documents and multimedia, and support real-time collaboration with version control. This requires a scalable ingestion pipeline, specialized AWS services for different content types, and a real-time collaboration layer with proper storage separation.

🟢 Correct Option:

B. Use Amazon Bedrock Data Automation (BDA) with foundation models (FMs) to process document files. Integrate BDA with Amazon Textract for PDF extraction and with Amazon Transcribe for multimedia files. Store the processed content in Amazon S3 with versioning enabled. Store the metadata in Amazon DynamoDB. Collaborate in real time by using AWS AppSync GraphQL subscriptions and DynamoDB.
This option is correct because it uses the right AWS services for each workload: Textract for document extraction, Transcribe for video/audio processing, and BDA for orchestration and summarization. S3 versioning ensures content history and traceability. DynamoDB handles metadata at scale. AWS AppSync provides real-time collaboration through GraphQL subscriptions, making it suitable for concurrent updates and version-controlled study material generation.

🔴 Incorrect options:

A. Use Amazon Bedrock Data Automation (BDA) with AWS Lambda functions to orchestrate document file processing. Use Amazon Bedrock Knowledge Bases to process all multimedia. Store the content in Amazon DocumentDB with replication. Collaborate by using Amazon SNS topic subscriptions. Track changes by using Amazon Bedrock Agents.
This is misaligned because Knowledge Bases are not designed for multimedia processing pipelines. SNS is not suitable for real-time collaboration. DocumentDB adds unnecessary complexity, and Bedrock Agents are not designed for version tracking or content collaboration workflows.

C. Use Amazon Bedrock Data Automation (BDA) with Amazon SageMaker AI endpoints to host content extraction and summarization models. Use Amazon Bedrock Guardrails to extract content from all file types. Store document files in Amazon Neptune for time series analysis. Collaborate by using Amazon Bedrock Chat for real-time messaging.
Guardrails do not extract or process files; they only enforce safety constraints. Neptune is a graph database and not suited for storing large-scale document or media content. Bedrock Chat is not a collaboration or version control system.

D. Use Amazon Bedrock Data Automation (BDA) with AWS Lambda functions to process batches of content files. Fine-tune foundation models (FMs) in Amazon Bedrock to classify documents across all content types. Store the processed data in Amazon ElastiCache (Redis OSS) by using Cluster Mode with sharding. Use Prompt management in Amazon Bedrock for version control.
ElastiCache is not suitable for persistent storage or collaboration workflows. Prompt management is only for managing prompts, not version control of generated study materials. Fine-tuning all content types for classification is inefficient and unnecessary for ingestion pipelines at this scale.

🔧 Reference:
⇒ Amazon Textract Documentation
Explains how Amazon Textract extracts structured data from documents such as PDFs and forms.

A.   Integrate an Amazon API Gateway HTTP API with an AWS Lambda function to invoke Amazon Bedrock. Use Lambda response streaming to stream responses. Enforce token limits within the Lambda function. Implement retry logic for model timeouts by using Lambda and API Gateway timeout configurations.

Explanation:

This question tests the ability to design a serverless API architecture that supports response streaming, token limit enforcement, and retry logic for a Bedrock-hosted FM — all with the least operational overhead. The key differentiators are the API Gateway type selected, streaming support, and infrastructure management requirements.

✅ Correct Option — A:
API Gateway HTTP APIs are lighter, faster, and lower cost than REST APIs, making them the optimal choice for streaming-focused GenAI workloads. Lambda response streaming delivers tokens progressively to reduce perceived latency. Token limits are enforced directly in Lambda code without additional services. Native Lambda and API Gateway timeout configurations handle retries for model timeouts and partial responses — all within a fully serverless, minimally managed architecture.

❌ Incorrect Options:

B. API Gateway HTTP API with client-side polling and frontend token enforcement:
Simulating streaming via client-side polling introduces unnecessary latency and complexity, defeating the core streaming requirement. Enforcing token limits on the frontend is unreliable and insecure, as it bypasses server-side control. This approach does not genuinely satisfy streaming or robust retry logic requirements at the API layer.

C. API Gateway WebSocket API with ECS containerized inference server:
Running a containerized inference server on Amazon ECS introduces significant operational overhead including cluster management, task scaling, lifecycle hooks, and container maintenance. WebSocket connections add connection state complexity. This architecture far exceeds the operational simplicity required, especially when serverless alternatives natively satisfy all stated requirements.

D. API Gateway REST API with Lambda streaming and retry logic:
REST APIs in API Gateway carry higher latency, greater configuration complexity, and higher cost compared to HTTP APIs for streaming use cases. Lambda response streaming is not natively supported through API Gateway REST API integrations in the same optimized manner as HTTP APIs, making this a functionally inferior and costlier choice than Option A.

🔧 Reference:
⇒ AWS Lambda Response Streaming → Confirms Lambda's native support for response streaming, enabling progressive token delivery to reduce latency in GenAI applications.

⇒ Amazon API Gateway HTTP APIs → Confirms HTTP APIs as the lower-latency, lower-cost alternative to REST APIs, optimized for proxy integrations including Lambda streaming responses.

A.   Store document timestamps in Amazon S3 system metadata. Use S3 object tags for domain classification. Implement custom user-defined metadata to store author information.

Explanation:

This question tests your knowledge of implementing a metadata framework on Amazon S3 that provides comprehensive context to foundation models. The solution must leverage the native S3 metadata capabilities effectively—system metadata for timestamps, user-defined metadata for custom attributes like author information, and object tags for categorization and searchable key-value pairs.

✔️ Option A (Correct Option):
This solution correctly utilizes S3's native metadata capabilities. S3 system metadata automatically captures timestamps such as last-modified and creation-date without manual effort . S3 object tags (key-value pairs) provide a flexible way to categorize documents with domain classifications and are searchable via S3 Select or Athena. Custom user-defined metadata allows storing author information by setting x-amz-meta-author headers, which maintains a consistent metadata structure. This approach ensures FMs can understand document context through descriptive metadata without accessing the full content .

❌ Option B (Incorrect Option):
This solution misuses S3 features. S3 Object Lock with legal holds is designed for compliance and preventing object deletion, not for tracking document timestamps. S3 access points simplify data access management but are not intended for domain classification—they control network permissions, not metadata attributes. Author information stored in tags would be inefficient as tags are better suited for searchable classification.

❌ Option C (Incorrect Option):
This approach uses entirely inappropriate services. S3 Inventory reports provide daily or weekly lists of objects and their metadata but are not a storage location for timestamps. S3 Storage Lens is an organizational-level dashboard for storage usage and activity metrics, not for storing per-object metadata like author information. Access points do not serve as a classification mechanism.

❌ Option D (Incorrect Option):
S3 Object Lock retention periods define how long objects are protected from deletion—they are not a mechanism for storing timestamps. S3 Event Notifications trigger actions based on events like object creation but do not store or manage classification metadata. This solution fails to provide a consistent, queryable metadata framework necessary for both human and FM-driven search.

🔧 Reference:
→ AWS S3 Documentation: Tagging your objects. Confirms that S3 object tags are key-value pairs for categorizing storage and support search capabilities.

→ AWS S3 Documentation: Working with object metadata. Confirms custom metadata can be stored using x-amz-meta- prefixes to create a consistent structure.

A.   Use AWS Amplify AI Kit to implement streaming responses from the GraphQL API and to optimize client-side rendering.

Explanation:

This question addresses real-time response latency bottlenecks when handling complex generative AI queries. RequestResponse-based AWS Lambda resolvers block the connection until the entire response is assembled, causing severe client-side timeouts. Introducing a streaming mechanism resolves the perceived latency issues by feeding partial data back to the user instantly.

✅ Correct Option:

Option A
The AWS Amplify AI Kit provides native capabilities designed specifically for full-stack generative AI applications. By switching to Amplify AI Kit conversation routes, the backend automatically sets up streaming orchestration over AWS AppSync WebSockets. This allows the backend Lambda to stream incoming chunks from the foundation model directly to the client, providing a fast, continuous user experience that completely eliminates the RequestResponse timeout barrier.

❌ Incorrect options:

Option B
Increasing the timeout value of the Lambda resolver and implementing exponential backoff retries merely treats the symptom without fixing the underlying architectural bottleneck. Because the frontend still has to wait synchronously for the entire multi-paragraph response to complete, the client-side experience remains slow and prone to browser-level connection failures.

Option C
Routing requests through an Amazon SQS queue and having an AppSync resolver poll it converts a synchronous operation into an overly complex asynchronous batch pipeline. This approach is completely unsuited for an interactive AI assistant because it introduces massive polling delays and fails to offer the immediate token-by-token streaming required by end users.

Option D
While changing to the InvokeModelWithResponseStream API and implementing an Amazon API Gateway WebSocket endpoint provides a valid technical streaming path, it fails the requirement to minimize implementation overhead. This method forces the development team to manually manage raw WebSocket connection states, custom routes, and complex client state-tracking logic, discarding the company's existing AWS Amplify and AppSync frameworks.

🔧 Reference:
→ AWS Documentation: Build fullstack AI apps with AWS Amplify AI Kit confirms that the Amplify AI kit bypasses traditional HTTP blocking by natively streaming real-time token chunks directly to the browser via managed chat routes.

→ AWS Amazon Blog: Build AI apps in minutes with the AWS Amplify AI Kit details how full-stack conversation routes handle managed backend integrations with Bedrock to deliver low-latency streaming interfaces.

A.   Enable model preload upon container startup. Implement dynamic batching to process multiple user requests together in a single inference pass.

D.   Set the minimum number of instances to greater than 0. Enable response streaming.

Explanation:

This question focuses on reducing p95 latency and Time to First Token (TTFT) for an interactive LLM chat assistant on SageMaker real-time endpoints. High abandonment after 2 seconds highlights cold starts and slow token delivery as key problems. The target is sub-800 ms p95 latency for responsive user experience.

✅ Correct Option A:
Enabling model preload upon container startup avoids loading delays on initial requests. Dynamic batching processes multiple concurrent user requests in one inference pass, improving throughput and efficiency for variable chat traffic while maintaining low latency. This combination directly addresses inconsistent response times in real-time LLM serving.

✅ Correct Option D:
Setting minimum instances greater than 0 keeps endpoints warm and eliminates cold starts during scaling. Response streaming delivers tokens as they are generated, significantly improving perceived latency and user engagement for chat applications, even when full responses take longer. This meets interactive p95 latency requirements effectively.

❌ Incorrect Option B:
Larger GPU instances increase compute power but setting minimum instances to 0 allows cold starts. Lazy loading on first request further delays TTFT, harming p95 latency for interactive chats.

❌ Incorrect Option C:
Multi-model endpoints rely on lazy loading, causing unpredictable load times and potential unloading of models. Without batching, concurrency and throughput remain unoptimized for stable low-latency performance.

❌ Incorrect Option E:
Asynchronous Inference suits batch or long-running non-interactive jobs with S3 queuing. It introduces delays unsuitable for real-time chat needing p95 latency under 800 ms.

🔧 Reference:
→ Amazon SageMaker Documentation - Real-time Inference
Confirms real-time endpoints for low-latency interactive workloads and support for response streaming.

→ AWS Blog - Elevating the generative AI experience: Introducing streaming support in Amazon SageMaker hosting
Details how response streaming lowers perceived latency for LLM chat applications.

A.   Use Amazon Bedrock Prompt Management to specify the required inputs as variables. Select an Amazon Nova Pro FM. Specify the output format for the response. Add the prompt to the prompts node of the flow.

D.   Create an Amazon Bedrock guardrail that applies the insults content filter. Set the filter response to detect. Add the guardrail to the prompts node of the flow.

Explanation:

This question assesses your knowledge of Amazon Bedrock Flows, Prompt Management, and Guardrails. The application needs structured inputs with consistent output formatting and monitoring for bullying language without blocking responses. The correct solutions combine Prompt Management for input/output control and Guardrails with detection mode for non-blocking monitoring of harmful content.

✔️ Option A
Use Amazon Bedrock Prompt Management to specify the required inputs as variables. Select an Amazon Nova Pro FM. Specify the output format for the response. Add the prompt to the prompts node of the flow.
Prompt Management allows you to define variables for the four required inputs and specify the exact output format, ensuring consistent responses from the Nova Pro FM. You can add the configured prompt to the prompts node of the flow, where variables are filled from input nodes .

✔️ Option D
Create an Amazon Bedrock guardrail that applies the insults content filter. Set the filter response to detect. Add the guardrail to the prompts node of the flow.
The insults content filter detects harmful content categories including bullying language . Setting the filter action to "detect" (also known as NONE mode) monitors and logs flagged content without blocking it, satisfying the requirement to receive notifications without blocking all responses . Guardrails can be added to the prompts node configuration .

❌ Option B
Create an Amazon Bedrock guardrail that applies the hate content filter. Set the filter response to block. Add the guardrail to the prompts node of the flow.
While the hate filter can detect harmful content, "block" is the incorrect action. The company explicitly does not want to block flagged responses; they only want to receive notifications. The hate category is also less appropriate than the insults category for detecting bullying language.

❌ Option C
Create an Amazon Bedrock prompt router. Specify an Amazon Nova Pro FM. Add the required inputs as variables to the input node of the flow. Add the prompt router to the prompts node. Add the output format to the output node.
Prompt routers are not a feature of Amazon Bedrock Flows. The correct approach uses Prompt Management for defining the prompt with variables and output format, not a router. This option describes an invalid architecture component for the given scenario.

❌ Option E
Create an Amazon Bedrock application inference profile that specifies an Amazon Nova Pro FM. Specify the output format for the response in the description. Include a tag for each of the input variables. Add the profile to the prompts node of the flow.
Inference profiles are used for model routing across different regions or for model distillation, not for managing prompts with variables and output formats. This approach does not align with how Prompt Management and Flows handle structured inputs and outputs.

🔧 Reference:
→ Amazon Bedrock Guardrails - Detect and filter harmful content - Confirms that content filters including the Insults category can be configured to detect harmful text in model responses.

→ Amazon Bedrock Flows - PromptFlowNodeConfiguration - Confirms that guardrails can be applied to prompt nodes and that prompts from Prompt Management with variables can be used in flows.

A.   Use AWS Glue Data Catalog to register all data sources and track lineage. Use Amazon Bedrock Guardrails PII filters. Enable AWS CloudTrail logging for all Amazon Bedrock API calls with Amazon S3 integration. Use Amazon Macie to scan stored data for sensitive information and publish findings to Amazon CloudWatch Logs. Create CloudWatch dashboards to visualize the findings and generate automated compliance reports.

Explanation:

This question tests end-to-end governance for GenAI workloads on AWS, specifically:

data lineage tracking across multiple sources
real-time PII detection during model interaction
audit logging for compliance reporting
continuous sensitive data discovery in storage

The solution must combine data cataloging, runtime guardrails, audit logging, and data scanning tools.

🟢 Correct Option:

A. Integrated AWS governance + Bedrock security stack
AWS Glue Data Catalog provides centralized metadata management and supports tracking data lineage across multiple sources. Bedrock Guardrails enables real-time PII filtering during inference, ensuring sensitive data is detected as it is processed. CloudTrail logs all Bedrock API activity for auditability, while S3 stores logs for long-term compliance. Macie scans stored datasets for sensitive data and CloudWatch visualizes and automates compliance reporting.

🔴 Incorrect Options:

B. AWS Config + WAF + EventBridge + Comprehend Medical
This option is incorrect because AWS Config tracks configuration changes, not full data lineage. WAF operates at HTTP request filtering and is not designed for PII detection inside GenAI prompts. Comprehend Medical is domain-specific (clinical text) and not suitable for general compliance pipelines. Overall, it lacks unified lineage and proper Bedrock-native guardrails.

C. DataSync + Macie + Session Manager + Textract
This approach misuses services. DataSync replicates data but does not track lineage. Macie is applied incorrectly to Bedrock outputs rather than storage layers. Session Manager logs sessions but not structured AI inference audit trails. Textract and Step Functions are unrelated to real-time PII filtering in generative AI workflows.

D. Athena + CloudWatch metrics + X-Ray + Rekognition
Athena is a query engine, not a lineage tracking system. CloudWatch custom metrics cannot reliably detect PII in model outputs. X-Ray traces service calls but does not provide compliance-grade audit trails for data governance. Rekognition Custom Labels is designed for image classification, not text-based PII detection in GenAI systems.

🔧 Reference:
→ Amazon Bedrock Guardrails
Explains how Guardrails can enforce real-time PII detection and content filtering during inference.

→ What is AWS Glue?
Describes how AWS Glue Data Catalog centralizes metadata and supports data lineage tracking across sources.

D.   Use AWS Glue Data Catalog to register all data sources. Apply metadata tags to attribute data sources. Use AWS CloudTrail to log access and activity across services.

Explanation:

This question evaluates the architecture required to achieve full traceability and data lineage in a generative AI pipeline. The key requirements are centralized data source registration, descriptive metadata tagging for content attribution, and comprehensive audit logging across the entire pipeline.

✅ Correct Option:

Option D
This choice fulfills all compliance and traceability requirements. AWS Glue Data Catalog serves as the centralized repository to register disparate internal and external data sources. It natively supports metadata tagging for precise source attribution, while AWS CloudTrail provides the mandatory pipeline-wide audit logs by capturing API activity across all participating AWS services.

❌ Incorrect options:

Option A
While AWS Lake Formation provides robust data governance and access control, it relies on the AWS Glue Data Catalog for underlying metadata storage. Applying metadata tags directly to Amazon S3 objects becomes decentralized and unmanageable across diverse external data sources, failing the requirement for unified source registration.

Option B
AWS Glue Data Catalog is appropriate for registration and tagging, but Amazon CloudWatch Logs is insufficient on its own for compliance auditing. CloudWatch Logs captures application-level behavior and stdout/stderr streams, whereas AWS CloudTrail is specifically required to track granular API access and service-to-service usage across the entire pipeline.

Option C
Using Amazon S3 object tagging is effective only for data residing inside S3, failing to seamlessly handle and attribute external data sources mentioned in the scenario. Additionally, AWS Glue is restricted here to schema management rather than acting as the central registration and metadata tracking hub required for end-to-end lineage.

🔧 Reference:
→ Learn how Populating the AWS Glue Data Catalog enables centralized data source registration and metadata management.

→ Read about tracking data access history and compliance across services using Logging AWS Glue API calls with AWS CloudTrail.

D.   Create an Amazon Q Developer customization that includes the approved data sources. Ensure that the developers use the customization to develop the application.

Explanation:

This question tests the distinction between Amazon Q Developer customizations (organization-level, Pro-only feature for internal libraries/code style) versus workspace context or project rules (project-level modifications). The key requirement is enforcing approved resources without making project-level changes.

✔️ Correct Option: Option D
Amazon Q Developer customizations are designed specifically for Amazon Q Developer Pro subscribers to provide in-line code suggestions based on a company's internal codebase, including internal libraries, proprietary algorithmic techniques, and approved coding styles. Customizations are created at the organization level in the Amazon Q Developer console, connected to data sources via AWS CodeConnections or Amazon S3, and shared with user groups. This meets the requirement because developers use the customization without modifying the project itself, and it applies across all projects without project-level changes.

❌ Incorrect Option: Option A
Workspace context (using @workspace) creates a local index of the current workspace repository and requires developers to explicitly add @workspace to their questions. This is project-level because the Git repository must be included locally in each application workspace, violating the "no project-level modifications" requirement. It also relies on manual developer action rather than enforced organization-level configuration.

❌ Incorrect Option: Option B
The amazonq/rules folder name is incorrect. Project rules must be stored in .amazonq/rules (with a leading dot), not amazonq/rules. Additionally, project rules are defined in Markdown files containing prompts/guidelines—not by storing actual libraries, algorithms, or code samples. This approach requires project-level folder creation, violating the requirement.

❌ Incorrect Option: Option C
Using a generic rules folder is incorrect because Amazon Q Developer specifically requires the .amazonq/rules folder path for project rules. More importantly, project rules contain Markdown files with coding guidelines and prompts—not actual code libraries or algorithmic techniques. This solution also requires project-level folder creation, which violates the no-project-modification requirement.

🔧 Reference:
→ AWS Documentation – What is Amazon Q Developer? — Confirms that customizations enable Amazon Q Developer to provide in-line suggestions based on company codebases (internal libraries, proprietary techniques, code style) and are created at the organization level without project modifications.

→ AWS Prescriptive Guidance – Advanced capabilities of Amazon Q Developer — Confirms customizations provide suggestions based on company code repositories via Amazon S3 or AWS CodeConnections, distinct from workspace context.

C.   Configure Amazon Bedrock to store model invocation logs in an Amazon S3 bucket. Enable text output logging. Configure Amazon Bedrock guardrails to run contextual grounding checks to detect hallucinations. Create Amazon CloudWatch anomaly detection alarms for token usage metrics.

Explanation:

This question tests near real-time monitoring strategies for generative AI applications on Amazon Bedrock, focusing on hallucination detection in clinical summaries, token usage anomalies, and cost control with minimal custom code and maintenance.

✅ Correct Option C:
Configuring model invocation logging to S3 with text output enables detailed capture of inputs and outputs. Amazon Bedrock guardrails with contextual grounding checks detect hallucinations by validating responses against source documents in near real-time. CloudWatch anomaly detection on token metrics provides early warnings for abnormal consumption and cost spikes without heavy custom development.

❌ Incorrect Option A:
CloudWatch alarms monitor token counts effectively, but using AWS Glue and Athena for hallucination detection relies on batch querying of S3 logs, which is not near real-time and requires more maintenance for ongoing analysis.

❌ Incorrect Option B:
Bedrock evaluation jobs are suitable for periodic offline assessments rather than near real-time monitoring. Adding a Lambda function for notifications increases custom development and maintenance overhead compared to built-in features.

❌ Incorrect Option D:
AWS CloudTrail logs API calls for auditing but lacks detailed token usage metrics. SageMaker Model Monitor is designed for custom SageMaker models, not Bedrock-hosted foundation models, making it a poor fit with higher complexity.

🔧 Reference:
→ Amazon Bedrock User Guide - Contextual Grounding Check
Confirms guardrails detect hallucinations in model responses using grounding checks.

→ Amazon Bedrock User Guide - Model Invocation Logging
Details logging to S3/CloudWatch and integration with anomaly detection for token usage monitoring.

B.   Extend the existing SCPs to enable CRI for the eu.amazon.nova-pro-v1:0 inference profile

D.   Validate that the GenAI developer IAM roles have permissions to invoke Amazon Nova Pro through the eu.amazon.nova-pro-v1:0 inference profile on all European Union AWS Regions that can serve the model

Explanation:

The error occurs because the SCP blocks access to eu-west-3, which is a destination region for the EU Nova Pro inference profile. The solution must allow CRI while preserving regional governance. This requires both SCP exceptions for the inference profile and proper IAM permissions for developers.

✔️ Option B
Extend the existing SCPs to enable CRI for the eu.amazon.nova-pro-v1:0 inference profile.
The SCP is explicitly denying the action on the eu-west-3 region resource. The EU Nova Pro inference profile routes requests across eu-central-1, eu-north-1, eu-west-1, and eu-west-3. If any destination region in the profile is blocked by SCPs, the request fails even if other regions remain allowed. You must extend the SCP to create an exception for bedrock:InvokeModel* actions on the eu.amazon.nova-pro-v1:0 inference profile to allow cross-region inference while maintaining other regional restrictions. This preserves existing governance controls while enabling CRI.

✔️ Option D
Validate that the GenAI developer IAM roles have permissions to invoke Amazon Nova Pro through the eu.amazon.nova-pro-v1:0 inference profile on all European Union AWS Regions that can serve the model.
IAM roles need permissions for bedrock:InvokeModel* actions on the inference profile resource. You must validate that the IAM role policies include the inference profile ARN and not just the base model ID. The eu.amazon.nova-pro-v1:0 inference profile ARN should be specified as the modelId for cross-region inference. Additionally, SCPs and IAM policies work together to control where cross-region inference is allowed, so both must be validated for all destination regions in the EU inference profile.

❌ Option A
Add an AdministratorAccess policy to the GenAI developer IAM role.
AdministratorAccess is an over-permissive policy that violates least privilege principles and the company's precise access control requirement. Moreover, the error is caused by an SCP denial, not insufficient IAM permissions. Adding AdministratorAccess would not resolve the SCP restriction and would create a significant security risk.

❌ Option C
Enable Amazon Bedrock model access for Amazon Nova Pro in the eu-west-3 Region.
The company's data residency policy requires using only the eu-central-1 region for all operations. Enabling model access in eu-west-3 would violate this policy. Furthermore, with CRI, you do not need to separately enable model access in destination regions because requests are routed through the inference profile from the source region.

❌ Option E
Extend the existing SCP to enable CRI for the eu-* inference profile.
The eu-* wildcard is too broad and would create an exception for all EU inference profiles, violating the precise access control requirement. The solution must target only the specific inference profile needed: eu.amazon.nova-pro-v1:0. A wildcard exception could inadvertently allow access to other models or profiles that are not approved.

🔧 Reference:
→ Supported Regions and models for inference profiles - Amazon Bedrock - Confirms that the EU Nova Pro inference profile routes requests across eu-central-1, eu-north-1, eu-west-1, and eu-west-3.

→ Increase throughput with cross-Region inference - Amazon Bedrock - Confirms that SCPs must allow all destination regions in a profile and that IAM policies control which roles can run inference.

A.   Use Amazon Bedrock Knowledge Bases to generate embeddings. Store the embeddings as a vector store in Amazon OpenSearch Service. Create an AWS Lambda function that queries the knowledge base. Configure Amazon API Gateway to invoke the Lambda function when handling user requests.

Explanation:

This question tests RAG (Retrieval-Augmented Generation) architecture at scale using Amazon Bedrock, focusing on:

semantic search over large unstructured + structured text (books, reviews, metadata)
low-latency retrieval for conversational recommendations
high scalability for 10,000+ concurrent users
proper vector storage for embeddings

The key requirement is fast semantic retrieval + scalable vector search backend.

🟢 Correct Option:

A. Bedrock Knowledge Bases + OpenSearch vector store
Amazon Bedrock Knowledge Bases automatically converts S3 data into embeddings and supports RAG workflows. Amazon OpenSearch Service is optimized for high-performance vector similarity search, making it suitable for low-latency recommendation queries at scale. Lambda acts as a lightweight orchestration layer, while API Gateway provides scalable access for thousands of concurrent users. This combination ensures fast, semantic, and scalable recommendation responses.

🔴 Incorrect Options:

B. Using DynamoDB as a vector store
DynamoDB is not designed for vector similarity search or embedding-based retrieval. It excels at key-value access, not semantic search. Using it as a vector store would result in poor relevance and inefficient retrieval performance, especially under high concurrency and large embedding datasets.

C. SageMaker endpoint recommendation engine
SageMaker can host ML models, but it is not optimized for RAG-based conversational retrieval from large unstructured document corpora. It would require custom feature engineering, lacks built-in knowledge ingestion from S3, and increases operational complexity for a use case that Bedrock Knowledge Bases already solves natively.

D. Amazon Kendra GenAI Enterprise Edition
Kendra is good for enterprise search, but it is not the best fit for custom generative AI recommendation systems requiring embedding-based conversational RAG pipelines. It also introduces tighter indexing constraints and less flexibility compared to Bedrock + OpenSearch for large-scale generative recommendation workloads.

🔧 Reference:
→ Amazon Bedrock Knowledge Bases
Explains how Bedrock Knowledge Bases convert documents into embeddings and support RAG workflows using vector stores.

→ Amazon OpenSearch Service Vector Search
Describes OpenSearch support for high-performance vector similarity search used in large-scale AI retrieval systems.