Free AIP-C01 Practice Test Questions 2026

C.   Enable Amazon CloudWatch Application Insights for the application resources. Create custom metrics for recommendation quality, token usage, and response latency by using the CloudWatch embedded metric format with dimensions for request types and user segments. Configure CloudWatch anomaly detection on the model metrics. Establish log pattern analysis by using CloudWatch Logs Insights.

Explanation:

This question tests your ability to design an observability and alerting architecture for generative AI systems on AWS. It focuses on tracking model performance degradation against baselines, analyzing multidimensional telemetry, and leveraging machine learning-driven anomaly detection to trigger alerts within a strict time window.

✅ Correct Option:

Option C
This option fulfills all observability, baseline monitoring, and rapid alerting criteria. Amazon CloudWatch Application Insights automatically monitors the underlying application resources. Utilizing the CloudWatch embedded metric format allows the system to ingest high-cardinality custom metrics (like quality and token usage) with rich dimensions. CloudWatch anomaly detection continuously models these metrics against historical baselines, instantly triggering alarms within the 10-minute threshold when model behavior drifts.

❌ Incorrect options:

Option A
CloudWatch Container Insights is explicitly designed to monitor containerized environments such as Amazon ECS or Amazon EKS. Because this specific recommendation system's applications run directly on Amazon EC2 instances rather than containers, deploying Container Insights is architecturally incorrect and fails to monitor the target infrastructure.

Option B
While AWS X-Ray and CloudTrail provide valuable distributed tracing and API audit logs, this combination lacks a native mechanism to automatically detect operational performance degradation against established baselines. Furthermore, utilizing Amazon QuickSight for real-time operational alerting within 10 minutes introduces unnecessary complexity and dashboard latency compared to native CloudWatch alarms.

Option D
Deploying Amazon OpenSearch Service alongside Amazon Kinesis creates an excessively complex architecture with high operational overhead. While it can ingest and query data using Piped Processing Language (PPL), it does not provide the seamless, automated, machine learning-backed baseline anomaly detection and native 10-minute threshold alerting that CloudWatch offers out of the box.

🔧 Reference:
→ Learn about automated resource monitoring and baseline tracking via Amazon CloudWatch Application Insights.

→ Review how to detect statistical deviations and behavior changes using CloudWatch Anomaly Detection.

D.   Use Amazon Titan Embeddings in Amazon Bedrock to create vector representations of the digitized files. Store embeddings in an Amazon Aurora PostgreSQL Serverless database that has the pgvector extension.

Explanation:

This question tests the optimal AWS solution for semantic search (vector similarity) with text and metadata filtering while minimizing operational overhead for under 1 million files. Key requirements include: vector embeddings for text similarity, metadata-based filtering, and no keyword metadata.

✔️ Correct Option: Option D
Amazon Titan Embeddings in Amazon Bedrock is a fully managed, serverless API service that requires zero infrastructure provisioning, endpoint management, or model deployment—delivering near-zero operational overhead. Amazon Aurora PostgreSQL Serverless with pgvector automatically scales compute and storage based on demand, pauses during inactivity to eliminate idle costs, and supports vector similarity search with HNSW indexing. This combination enables efficient semantic search with metadata filtering (PostgreSQL's native query capabilities) while requiring minimal operational management compared to managed OpenSearch clusters or SageMaker endpoints.

❌ Incorrect Option: Option A
Amazon OpenSearch Service with the Neural plugin requires managing OpenSearch Compute Units (OCUs) with a minimum of 2 OCUs for production (~$350/month idle cost), dedicated OCUs for vector collections, and cluster maintenance. While OpenSearch supports semantic search, it has significantly higher operational overhead than Aurora Serverless due to OCUs provisioning, cluster scaling, and indexing management. Additionally, OpenSearch Serverless vector collections cannot share OCUs with other collection types, increasing complexity and cost for this use case.

❌ Incorrect Option: Option B
Amazon Comprehend extracts topics/sentiment but does not create vector embeddings required for semantic similarity matching based on text similarity. Topic extraction produces categorical labels rather than dense vector representations, making it impossible to "match similar abstracts to one another based on the similarity of their text" as required. Aurora PostgreSQL without pgvector cannot perform vector similarity search, and Comprehend topics don't support the semantic similarity requirement for journal abstract matching.

❌ Incorrect Option: Option C
Amazon SageMaker AI requires deploying and managing a sentence-transformer model endpoint (e.g., Hugging Face), which involves provisioning inference instances (ml.g5.xlarge ~$1.21/hr = ~$875/month idle cost), endpoint monitoring, and model maintenance. This creates significantly higher operational overhead than Bedrock's serverless API approach. While pgvector in Aurora PostgreSQL is correct for storage, the SageMaker deployment requirement makes this option more complex than using Bedrock's managed Titan Embeddings service.

🔧 Reference:
→ AWS Documentation – Amazon Titan Text Embeddings models
— Confirms Titan Embeddings on Bedrock is completely serverless with no provisioning required, seamlessly integrating with Lambda and RDS/Aurora out of the box.

→ AWS What's New – Amazon Aurora PostgreSQL now supports pgvector
— Confirms Aurora PostgreSQL supports pgvector for storing embeddings from Bedrock/SageMaker and performing efficient similarity searches for semantic search and RAG applications.

B.   Implement an adaptive retry strategy that uses exponential backoff with jitter and a circuit breaker pattern that temporarily disables retries when error rates exceed a predefined threshold. Implement a streaming response handler that monitors for chunk delivery timeouts. Configure the handler to buffer successfully received chunks and intelligently resume streaming from the last received chunk when connections are reestablished.

Explanation:

This question evaluates resilient retry mechanisms for Amazon Bedrock API calls in high-load GenAI applications. It focuses on handling transient errors, preventing service overload, supporting response streaming with chunk recovery, token-aware processing, and adaptive behavior during peak periods.

✅ Correct Option B:
An adaptive retry strategy with exponential backoff and jitter automatically handles transient errors while preventing thundering herd issues that could overwhelm Bedrock. The circuit breaker pattern temporarily halts retries during high error rates, adapting to service availability. The streaming handler monitors chunk timeouts, buffers received data, and intelligently resumes from the last successful point, ensuring complete responses and token-aware handling.

❌ Incorrect Option A:
A fixed 1-second delay and simple retry limit do not adapt to changing conditions or prevent overload effectively. Basic stream restart loses partial progress and lacks intelligent token management for complex inquiries.

❌ Incorrect Option C:
Standard retry mode from the AWS SDK is less adaptive than the recommended approach for throttling-heavy workloads. While it includes some custom logic, the combination increases complexity without a circuit breaker and may not optimally handle streaming resumption or dynamic token limits.

❌ Incorrect Option D:
Static timeouts, load shedding, and fixed token caps provide basic protection but lack adaptive retries with jitter and proper circuit breaker behavior. This does not fully address streaming chunk recovery or dynamic adaptation to service availability.

🔧 Reference:
→ Amazon Bedrock Documentation - Optimize applications for scale and reliability
Confirms adaptive retries with exponential backoff, jitter, and circuit breakers for Bedrock resilience.

→ AWS Prescriptive Guidance - Retry with backoff pattern
Details exponential backoff with jitter and circuit breaker integration for transient error handling.

A.   In the application account, create interface VPC endpoints for Amazon Bedrock runtimes. Run Lambda functions in private subnets. Use IAM conditions on inference and data-plane policies to allow calls only to approved endpoints and roles. In the data storage account, use AWS Lake Formation LF-tag-based access control to create table-level and column-level cross-account grants.

Explanation:

This question assesses your knowledge of private connectivity to Amazon Bedrock and fine-grained data access across AWS accounts. The application needs to ensure Bedrock API calls remain within the VPC without traversing the public internet. The data lake requires column-level access controls for sensitive customer records. The correct solution combines VPC endpoints with IAM conditions and AWS Lake Formation for cross-account data governance.

✔️ Option A
In the application account, create interface VPC endpoints for Amazon Bedrock runtimes. Run Lambda functions in private subnets. Use IAM conditions on inference and data-plane policies to allow calls only to approved endpoints and roles. In the data storage account, use AWS Lake Formation LF-tag-based access control to create table-level and column-level cross-account grants.
Interface VPC endpoints for Bedrock runtime services enable private connectivity between the application VPC and Bedrock. Running Lambda functions in private subnets ensures traffic stays within the VPC. IAM conditions with aws:sourceVpce restrict Bedrock API calls to only those made through the approved VPC endpoints. In the data storage account, AWS Lake Formation LF-tags provide fine-grained column-level access controls across accounts, meeting the data lake requirement.

❌ Option B
Run Lambda functions in private subnets. Configure a NAT gateway to provide access to Amazon Bedrock and the data lake. Use S3 bucket policies and ACLs to manage permissions. Export AWS CloudTrail logs to Amazon S3 to perform weekly reviews.
A NAT gateway routes traffic through the public internet, violating the private connectivity requirement. S3 bucket policies and ACLs provide only coarse-grained access, not fine-grained column-level control across accounts. Weekly reviews are not an active governance solution for this requirement.

❌ Option C
Create a gateway endpoint only for Amazon S3 in the application account. Invoke Amazon Bedrock through public endpoints. Use database-level grants in AWS Lake Formation to manage data access. Stream AWS CloudTrail logs to Amazon CloudWatch Logs. Do not set up metric filters or alarms.
Invoking Bedrock through public endpoints violates the private connectivity requirement. Gateway endpoints are for S3 only and do not support Bedrock, which requires interface VPC endpoints. Database-level grants do not provide the required column-level granularity, and no alarms or filters fail to meet operational governance expectations.

❌ Option D
Use VPC endpoints to provide access to Amazon Bedrock and Amazon S3 in the application account. Use only IAM path-based policies to manage data lake access. Send AWS CloudTrail logs to Amazon CloudWatch Logs. Periodically create dashboards and allow public fallback for cross-Region reads to reduce setup time.
IAM path-based policies do not support the required column-level data lake access controls across accounts. Allowing public fallback for cross-Region reads violates the private connectivity and security requirements. This approach compromises both requirements for the sake of reduced setup time.

🔧 Reference:
→ Amazon Bedrock VPC Endpoints - AWS PrivateLink - Confirms that interface VPC endpoints for Bedrock runtime and data plane provide private connectivity between VPC and Bedrock.

→ AWS Lake Formation Cross-Account Access - Confirms that Lake Formation supports table-level and column-level permissions across AWS accounts using LF-tags and named resources.

B.   Configure an Amazon Bedrock integration to use the S3 bucket URI in the input parameters for large outputs. Use the ResultPath and ResultSelector fields to route S3 references between the agent steps while maintaining the sequential validation workflow.

Explanation:

This question is about Step Functions payload limits (256 KB) and how to design a scalable multi-agent GenAI pipeline using ReAct while minimizing operational overhead.

Key constraints:

Step Functions hard limit: 256 KB per state input/output
Intermediate reasoning traces are large
Must preserve sequential multi-agent workflow (ReAct pattern)
Must maintain low operational complexity

The correct design pattern is:

externalize large payloads to S3
pass only lightweight references (S3 URIs) between states
preserve orchestration flow using Step Functions fields like ResultPath

🟢 Correct Option:

B. S3-based payload offloading with Step Functions reference passing
This approach is the standard AWS pattern for handling large Step Functions payloads. Instead of passing full reasoning traces between states, outputs are stored in Amazon S3 and only the S3 URI is passed forward. ResultPath and ResultSelector allow controlled shaping of state input/output while preserving sequential execution. This maintains observability, supports the ReAct pattern, and avoids hitting the 256 KB payload limit without introducing additional infrastructure complexity.

🔴 Incorrect Options:

A. DynamoDB storage with Map state retrieval
This introduces unnecessary complexity and higher operational overhead. DynamoDB is not optimized for large sequential artifact storage like reasoning traces. Using a Map state also adds orchestration overhead and breaks the simple sequential ReAct flow. It increases read/write costs and latency without improving Step Functions payload handling efficiency.

C. Lambda compression/decompression
This approach adds unnecessary compute overhead and operational complexity. Compressing and decompressing every state increases latency, introduces failure points, and complicates debugging. It also does not align with AWS best practices for handling large Step Functions payloads, which recommend external storage instead of transformation within execution.

D. Multiple state machines + EventBridge coordination
This significantly increases architectural complexity and operational overhead. Splitting a single sequential ReAct workflow into multiple state machines reduces observability and makes debugging harder. EventBridge coordination introduces additional latency and failure domains, and still does not address the core issue as cleanly as S3 reference passing.

🔧 Reference:
→ AWS Step Functions service quotas
Explains the 256 KB payload limit and recommends using external storage like Amazon S3 for large data transfers between states.

→ AWS Discover service integration patterns in Step Functions
Describes how Step Functions can pass S3 references between states using input/output processing fields like ResultPath.

D.   Set up standardized multilingual test conversations with identical meaning. Run the test conversations in parallel by using Amazon Bedrock model evaluation jobs. Apply similarity and hallucination thresholds. Integrate the process into the CI/CD pipeline to block releases that fail.

Explanation:

This question tests your ability to design an automated, scalable model evaluation architecture for generative AI applications. The goal is to detect language-based performance drift and inconsistent responses in parallel across thousands of test cases, while integrating automated quality gates directly into a CI/CD pipeline.

✅ Correct Option:

Option D
This option efficiently meets all performance and automation requirements. Amazon Bedrock model evaluation jobs are fully managed, highly parallelizable, and capable of executing 15,000+ test conversations well within the 45-minute window. By defining identical-meaning multilingual datasets and establishing strict similarity and hallucination thresholds, the pipeline can programmatically evaluate outputs and block deployment if quality gates fail.

❌ Incorrect options:

Option A
This solution designs a load testing and traffic simulation framework focused on infrastructure and performance metrics like latency, concurrency, and throughput. While it helps identify physical resource bottlenecks, it does not evaluate model output quality, semantic consistency, or language-specific response accuracy across updates.

Option B
Deploying the application globally via Route 53 and Global Accelerator improves localized network performance and availability, but fails to solve the underlying problem. Relying on weekly post-deployment audits creates a lagging feedback loop that allows low-quality or hallucinated responses to reach production users instead of blocking them during building.

Option C
Normalizing input formats via a pre-processing pipeline does not prevent an upgraded foundation model from producing inconsistent or varying translations across languages. Relying strictly on rule-based checks is highly brittle for generative outputs and fails to scale dynamically across 15,000 parallel test conversations within a fast CI/CD pipeline.

🔧 Reference:
→ Learn about automated evaluation setups and quality assessment in Model evaluation.

→ Review dataset formatting and benchmarking metrics using Creating a model evaluation job.

B.   Deploy an Amazon Bedrock Knowledge Base and connect it to approved clinical source documents. Use the Amazon Bedrock RetrieveAndGenerate API to return citations from the knowledge base.

Explanation:

This question tests the optimal RAG (Retrieval Augmented Generation) solution in Amazon Bedrock for clinical decision support that requires source citations, no hallucinations, and least operational overhead. The key is using managed Bedrock features that automatically handle retrieval, generation, and citation.

✔️ Correct Option: Option B
Amazon Bedrock Knowledge Bases is a fully managed RAG service that automatically performs data ingestion, chunking, embedding, and retrieval from approved clinical documents. The RetrieveAndGenerate API operation returns responses with built-in citations to original source data, eliminating custom post-processing. This API queries the knowledge base and generates responses using the specified foundation model, with the response including a citations field containing generatedResponsePart and retrievedReferences for source verification. Bedrock's managed orchestration reduces operational overhead by eliminating custom retrieval logic, verification implementations, and manual citation handling—delivering the least operational overhead compared to custom API combinations or third-party integrations.

❌ Incorrect Option: Option A
Amazon Kendra is a separate enterprise search service that requires additional infrastructure setup, index management, and integration complexity beyond native Bedrock functionality. Implementing custom post-processing to compare generated responses against source documents requires building verification logic, document comparison algorithms, and citation injection—significant operational overhead. Kendra doesn't provide native Bedrock-generated citations with RetrieveAndGenerate, forcing manual implementation of source verification and citation inclusion that Bedrock handles automatically.

❌ Incorrect Option: Option C
Amazon Comprehend Medical extracts medical entities (conditions, medications, procedures) but does not create knowledge bases or perform retrieval-augmented generation for clinical decision support. Entity extraction alone cannot provide treatment recommendations based on approved documentation or generate citations—Comprehend Medical produces structured entity data rather than natural language responses with source references. Implementation verification logic against a medical terminology database requires building custom databases, comparison algorithms, and integration code, creating significant operational overhead without addressing the core requirement of source-based treatment recommendations.

❌ Incorrect Option: Option D
Using separate Retrieve API and InvokeModel API calls requires manual orchestration of retrieval then generation, eliminating the managed convenience of RetrieveAndGenerate. Implementing custom verification logic to compare responses against retrieved sources requires building document comparison algorithms, similarity scoring, and validation frameworks—significant operational overhead. The RetrieveAndGenerate API already provides built-in citations and source verification, making manual implementation redundant and more complex. This two-step approach also increases latency and error handling complexity compared to Bedrock's single API operation.

🔧 Reference:
→ AWS Documentation – Query a knowledge base and generate responses based on retrieved data
— Confirms RetrieveAndGenerate API returns responses with citations to original source data, eliminating custom post-processing for citation inclusion.

→ AWS Documentation – Citation
— Confirms RetrieveAndGenerate response includes citations field with generatedResponsePart and retrievedReferences for source verification and accuracy checking.

B.   Create the two prompt variants in Amazon Bedrock Prompt Management. Use Amazon Bedrock Flows to deploy the prompt variants with defined traffic allocation. Configure Amazon Bedrock guardrails to monitor demographic fairness. Set up Amazon CloudWatch alarms on the GuardrailContentSource dimension by using InvocationsIntervened metrics to detect recommendation discrepancy threshold violations.

Explanation:

This question tests implementing fairness monitoring and A/B testing for prompt variants in a Bedrock-based recommendation system. It requires real-time fairness metrics across demographics, alerts for discrepancies, weekly comparison reports, and minimal custom development.

✅ Correct Option B:
Amazon Bedrock Prompt Management allows creation and versioning of the two prompt variants for direct comparison. Bedrock Flows enables deployment with traffic allocation for live A/B testing. Guardrails monitor demographic fairness through content and bias policies. CloudWatch alarms on relevant metrics (such as InvocationsIntervened) detect >15% discrepancies in real time and support weekly reports.

❌ Incorrect Option A:
Custom metrics and Lambda post-processing for fairness analysis introduce significant development and maintenance effort. It does not leverage native Bedrock features for prompt comparison or built-in monitoring.

❌ Incorrect Option C:
SageMaker Clarify is designed for traditional ML models rather than Bedrock foundation models and prompt variants. It requires more setup for real-time integration and ongoing monitoring compared to native Bedrock tools.

❌ Incorrect Option D:
Model evaluation jobs are suitable for one-time or batch comparisons of prompts but do not support continuous real-time fairness monitoring or automated alerts on live demographic discrepancies.

🔧 Reference:
→ Amazon Bedrock User Guide - Prompt management
Confirms creating and comparing prompt variants with versioning.

→ Amazon Bedrock User Guide - Detect and filter harmful content
Details monitoring and intervening on bias/fairness issues with CloudWatch integration.

B.   Implement Amazon Bedrock Guardrails with token quota policies. Capture metrics on rejected requests. Configure Amazon EventBridge rules to trigger notifications based on Amazon Bedrock Guardrails metrics. Use Amazon CloudWatch dashboards to visualize token usage trends across models.

Explanation:

This question assesses your knowledge of Amazon Bedrock's native token management, monitoring, and cost allocation capabilities. The company needs proactive alerting for token limits across multiple models, must handle high throughput of over 5,000 requests per minute, and requires cost allocation across business units. The correct solution leverages managed services that scale automatically and provide built-in monitoring and alerting.

✔️ Option B
Implement Amazon Bedrock Guardrails with token quota policies. Capture metrics on rejected requests. Configure Amazon EventBridge rules to trigger notifications based on Amazon Bedrock Guardrails metrics. Use Amazon CloudWatch dashboards to visualize token usage trends across models.
Amazon Bedrock Guardrails with token quota policies provide proactive enforcement when requests approach model-specific token limits, preventing overages before they occur. Guardrails automatically publish metrics to CloudWatch for rejected requests and token usage. EventBridge rules can trigger alerts based on these metrics, providing proactive notifications. CloudWatch dashboards visualize token usage trends across models and can display cost allocation tags for business unit reporting. This solution scales to handle 5,000+ requests per minute with no custom code.

❌ Option A
Develop model-specific tokenizers in an AWS Lambda function. Configure the Lambda function to estimate token usage before sending requests to Amazon Bedrock. Configure the Lambda function to publish metrics to Amazon CloudWatch and trigger alarms when requests approach thresholds. Store detailed token usage in Amazon DynamoDB to report costs.
Implementing custom tokenizers for each model in Lambda requires significant development and maintenance for each FM provider and model version. The Lambda function creates a synchronous pre-processing bottleneck that adds latency to every request. Storing detailed token data in DynamoDB for cost allocation requires additional custom code and does not leverage Bedrock's native tagging and metrics.

❌ Option C
Deploy an Amazon SQS dead-letter queue for failed requests. Configure an AWS Lambda function to analyze token-related failures. Use Amazon CloudWatch Logs Insights to generate reports on token usage patterns based on error logs from Amazon Bedrock API responses.
This solution only reacts to failures after they occur rather than proactively alerting before limits are reached. Analyzing error logs for token-related failures is reactive and does not prevent requests that exceed limits. CloudWatch Logs Insights for reporting requires custom query writing and does not provide the real-time dashboards needed for proactive monitoring.

❌ Option D
Use Amazon API Gateway to create a proxy for all Amazon Bedrock API calls. Configure request throttling based on custom usage plans with predefined token quotas. Configure API Gateway to reject requests that will exceed token limits.
API Gateway throttles based on request count, not token count, and cannot accurately predict token usage before invoking the model. Custom usage plans require pre-calculating tokens per request, which varies significantly. This proxy adds operational overhead and latency to all Bedrock API calls without providing model-specific token limit enforcement.

🔧 Reference:
→ Amazon Bedrock Guardrails - Manage token consumption with quotas - Confirms that token quota policies in guardrails help prevent exceeding model token limits and emit CloudWatch metrics for monitoring.

→ Monitor the bedrock-runtime endpoint - Confirms that CloudWatch metrics, dashboards, and AWS Cost Explorer with tags can be used to track token usage and allocate costs.

A.   Ensure that each customer sets up an Amazon Q Business index that includes the customer’s internal data. Ensure that each customer designates Example Corp as a data accessor to allow Example Corp to retrieve relevant content by using a secure API to enrich prompts at runtime.

Explanation:

This question tests customer-owned data access for Retrieval-Augmented Generation (RAG) while maintaining strong data governance.

The requirements emphasize:

customers retain ownership and control of their data
high semantic relevance for prompt enrichment
low retrieval latency
minimal operational complexity for Example Corp
no need to deploy and manage infrastructure in each customer environment

Amazon Q Business is specifically designed to provide secure access to customer-owned enterprise data while preserving governance boundaries.

🟢 Correct Option:

A. Amazon Q Business index with secure data accessor permissions
Amazon Q Business allows each customer to maintain ownership and control of its indexed enterprise data while enabling authorized access through secure APIs. Example Corp can retrieve only relevant content for prompt augmentation without managing separate retrieval infrastructure in each customer environment. This approach provides strong semantic retrieval quality, low-latency access, and a simplified architecture that aligns with customer governance requirements.

🔴 Incorrect Options:

B. Federated search with MCP servers for each customer
This option increases architectural complexity because Example Corp would need to deploy and maintain MCP infrastructure for every customer. The scenario explicitly states a desire to avoid managing services in customer environments unless necessary. Real-time federation also introduces additional operational and networking overhead.

C. Amazon Bedrock knowledge base with cross-account querying
Amazon Bedrock Knowledge Bases do not provide a standard cross-account query model where a third party directly retrieves customer knowledge base content. This approach also creates governance and access-control challenges and does not align as well with the requirement that customers maintain full ownership and control of their data.

D. Amazon Kendra indexes shared across accounts
Amazon Kendra is designed for enterprise search, but sharing indexes across accounts for third-party access is not the intended pattern. It introduces additional administration and governance complexity compared to Amazon Q Business and does not provide the same streamlined customer-controlled retrieval experience.

🔧 Reference:
→ Amazon Q Business Documentation
Explains how Amazon Q Business connects to enterprise data sources and provides secure retrieval while maintaining customer data control.

→ Security in Amazon Q Business
Describes access control and governance capabilities that help organizations retain ownership and control of their indexed data.

C.   Configure an AWS Lambda function to fetch routing configurations from the AWS AppConfig Agent for each user request. Run business logic in the Lambda function to select the appropriate FM for each request. Expose the FM through a single Amazon API Gateway REST API endpoint.

Explanation:

This question tests your ability to design a highly dynamic routing mechanism for generative AI workloads using decoupled logic and configuration management. The goal is to support frequent updates to routing data (like hourly cost fluctuations and complex evaluation matrices) and propagate those updates instantly across thousands of parallel requests without changing application code.

✅ Correct Option:

Option C
Using AWS AppConfig alongside the AWS AppConfig Agent extension in AWS Lambda is the ideal architecture for real-time dynamic configurations. The AppConfig Agent locally caches configuration metadata inside the Lambda execution environment, enabling sub-millisecond retrievals for each incoming user request. This lets the Lambda function run complex business logic evaluating real-time cost, compliance, and user context to switch between Amazon Bedrock models instantly with zero code redeployments.

❌ Incorrect options:

Option A
Updating AWS Lambda environment variables forces the creation of a new function version and initiates cold starts. This mechanism cannot propagate hourly changes instantly across thousands of active concurrent executions without creating processing overhead, nor is the Lambda console designed to manage complex, nested business routing rules safely.

Option B
Using Amazon API Gateway mapping templates and stage variables shifts complex business routing logic to the API perimeter, where it is incredibly brittle and difficult to maintain. Furthermore, updating stage variables cannot dynamically evaluate multi-dimensional runtime attributes like varying user tiers, region-specific regulations, and complex multi-model A/B tests.

Option D
Deploying AWS Lambda authorizers to process routing configurations forces the authorizer to handle routing orchestration rather than access control. Splitting the architecture into model-specific downstream Lambda functions creates immense operational overhead and increases code fragmentation, making simple runtime model swaps more complex than executing within a unified handler.

🔧 Reference:
→ Learn how to decouple code and configurations safely using What is AWS AppConfig? to manage live feature flags and operational controls.

→ Look into reducing application latency when querying flags by reading about the AWS AppConfig Agent implementation within serverless containers.

B.   Use AWS Step Functions with a Parallel state to invoke separate AWS Lambda functions for each analysis type simultaneously. Configure Amazon Bedrock client timeouts. Use Amazon CloudWatch metrics to track execution time and model inference latency.

Explanation:

This question tests the optimal AWS architecture for parallel processing of independent foundation model (FM) tasks to reduce batch processing time from 45 seconds to under 10 seconds. The key requirements are: parallel execution of multiple analysis types (financial data, sentiment, compliance), FM call orchestration, and strict time-bound execution.

✔️ Correct Option: Option B
AWS Step Functions with a Parallel state invokes multiple Lambda functions simultaneously rather than sequentially, enabling concurrent execution of independent analysis types (financial data extraction, sentiment analysis, compliance validation). This parallelization reduces total processing time from 45 seconds to approximately 10-15 seconds by executing all three analysis types concurrently instead of waiting for each to complete sequentially. The Parallel state provides built-in orchestration, error handling, and workflow visualization, while Bedrock client timeouts prevent indefinite waiting on model inference. CloudWatch metrics enable real-time monitoring of execution time and latency to ensure the 10-second constraint is met. Step Functions manages retries, state transitions, and execution tracking without custom code, delivering the most efficient solution for time-bound parallel FM workloads.

❌ Incorrect Option: Option A
AWS Lambda with provisioned concurrency still processes analysis types sequentially within a single function, failing to parallelize independent FM calls. Configuring 10-second timeouts contradicts the requirement since sequential processing takes 45 seconds total—each analysis type likely exceeds 10 seconds alone, causing timeout failures. Exponential backoff retries add additional latency rather than reducing it, moving further from the 10-second goal. Provisioned concurrency helps with concurrent batch requests but doesn't address parallelization of multiple analysis types within a single batch.

❌ Incorrect Option: Option C
Amazon SQS queues introduce sequential processing within each Lambda function, processing different aspects sequentially before combining results—this doesn't parallelize FM calls. SQS buffering adds latency through queue insertion, polling, and message retrieval overhead, increasing total processing time beyond 45 seconds rather than reducing it to 10 seconds. Reserved concurrency helps with concurrent batch processing but doesn't enable parallel execution of analysis types within a single batch. This architecture is designed for event-driven throughput, not time-bound parallel execution.

❌ Incorrect Option: Option D
Amazon ECS clusters running containers that process reports sequentially maintains the same 45-second bottleneck without parallelization. Load balancers distribute batch workloads across containers but don't parallelize analysis types within each batch—they spread batches across instances sequentially. Auto-scaling based on CPU utilization adds infrastructure management overhead (container orchestration, cluster scaling, load balancer configuration) without addressing the core parallelization requirement. ECS has higher operational complexity than serverless Lambda/Step Functions and doesn't reduce per-batch processing time.

🔧 Reference:
→ AWS Machine Learning Blog – Intelligent document processing using Amazon Bedrock
— Demonstrates document processing workflows using Bedrock FMs for data extraction and analysis, supporting multi-type analysis patterns.