AWS Generative AI Developer – Professional (AIP-C01) — Free Sample Questions
Practice with 30 free Generative AI Developer Professional questions covering Amazon Bedrock, model customization, RAG architectures, and responsible AI implementation on AWS.
Exam Domains
- Design and Architecture (30%) — choosing foundation models, designing RAG pipelines, vector database selection, agent architectures
- Model Selection and Customization (28%) — fine-tuning vs. continued pre-training, instruction tuning, PEFT/LoRA, evaluation metrics
- Application Development (26%) — Bedrock API integration, knowledge bases, guardrails configuration, streaming responses, prompt engineering
- Deployment and Operations (16%) — model endpoints, throughput provisioning, cost optimization, latency monitoring
What Makes AIP-C01 Unique
This is one of the newest AWS certifications, testing cutting-edge generative AI skills:
- Selecting the right foundation model (Claude, Titan, Llama) for specific use cases
- Designing efficient RAG systems with OpenSearch Serverless or Kendra
- Implementing guardrails: content filtering, PII redaction, hallucination reduction
- Building multi-step agents with Bedrock Agents and action groups
- Managing inference costs: on-demand vs. provisioned throughput
Study Focus Areas
- Understand Bedrock's model invocation API, streaming, and guardrails integration
- Know when to use RAG vs. fine-tuning vs. prompt engineering
- Study vector embedding models and chunking strategies
- Practice designing agent workflows with tools and knowledge base retrieval
Complete Preparation
Continue with 600 AIP-C01 questions — 30 quizzes and 2 full-length 75-question practice exams covering every domain and task statement.
All 30 Free Sample Questions
Question 1 — Domain 1: Foundation Model Integration, Data Management, and Compliance (31%)
A media company needs a GenAI solution that processes both live customer chat queries with sub-second latency and nightly bulk analysis of 50,000 articles cost-effectively. Which architecture supports both processing patterns?
- Use Amazon SQS with Lambda for all requests, adjusting Lambda reserved concurrency between real-time and batch workloads.
- Use a single API Gateway endpoint with Lambda, calling Bedrock InvokeModel for all requests regardless of processing type.
- Use API Gateway with Lambda for real-time requests calling Bedrock InvokeModel. Use S3 with EventBridge and Step Functions for batch processing using Bedrock batch inference. Both paths share prompt templates stored in Parameter Store. — Correct answer
- Use Amazon Bedrock Agents for real-time queries and a scheduled EventBridge rule triggering Lambda for batch processing with InvokeModel in a loop.
Explanation:
- Why C is correct: Separate processing paths optimize for different requirements. API Gateway + Lambda with InvokeModel provides low-latency synchronous responses for real-time chat. S3 + EventBridge + Step Functions with Bedrock batch inference (CreateModelInvocationJob) provides cost-effective asynchronous processing for 50,000 articles. Shared prompt templates in Parameter Store ensure consistency across both paths.
- Why A is wrong: A single SQS-based pipeline cannot optimize for both sub-second latency and bulk throughput simultaneously. Real-time requests compete with batch jobs for Lambda concurrency, and SQS introduces polling latency unsuitable for real-time chat.
- Why B is wrong: A single Lambda path using InvokeModel for all requests doesn't leverage Bedrock's batch inference API, which offers lower per-request cost for bulk operations. Processing 50,000 articles sequentially through InvokeModel is significantly more expensive and slower.
- Why D is wrong: Bedrock Agents add orchestration overhead (tool selection, reasoning loops) unnecessary for straightforward batch article analysis. Looping InvokeModel in Lambda for 50,000 articles risks timeout failures and is costlier than batch inference.
Question 2 — Domain 1: Foundation Model Integration, Data Management, and Compliance (31%)
A SaaS company processes thousands of customer support requests daily through Amazon Bedrock. Requests range from simple FAQ lookups to complex multi-step troubleshooting. The company wants to minimize foundation model costs while maintaining response quality for all request types. Which strategy BEST achieves this goal?
- Implement a Lambda-based routing layer that classifies request complexity using keyword analysis and input length, then routes simple requests to Amazon Titan Text Lite and complex requests to Anthropic Claude 3 Sonnet via Amazon Bedrock, with cost tracking in CloudWatch. — Correct answer
- Use Amazon Bedrock batch inference for all requests to take advantage of lower batch pricing, queuing requests in Amazon SQS and processing them every 5 minutes.
- Deploy a single mid-tier model such as Claude 3 Haiku for all requests to balance cost and quality, and increase provisioned throughput during peak hours.
- Route all requests through a single high-capability model with aggressive token limits and prompt compression to reduce per-request costs.
Explanation:
- Why A is correct: A tiered model strategy matches model capability to task complexity—simple tasks use cost-effective models while complex tasks use more capable (and expensive) models. Lambda-based routing enables this classification dynamically at request time. CloudWatch cost tracking provides visibility for ongoing optimization. This approach directly optimizes the cost-quality trade-off across varying complexity levels.
- Why B is wrong: Batch inference introduces up to 5-minute latency, which is unacceptable for customer support where users expect near-real-time responses. While batch pricing is lower per request, the latency trade-off fundamentally conflicts with the use case requirements.
- Why C is wrong: A single model for all requests either overpays for simple tasks (if using a capable model) or underperforms on complex tasks (if using a cheaper one). This approach does not optimize the cost-quality trade-off—it picks a fixed compromise point rather than matching model capability to actual need.
- Why D is wrong: Aggressive token limits and prompt compression can degrade response quality, especially for complex troubleshooting that requires detailed context. This sacrifices quality for cost reduction rather than intelligently matching models to task requirements.
Question 3 — Domain 1: Foundation Model Integration, Data Management, and Compliance (31%)
A financial services company feeds daily transaction summaries into an FM for report generation. The data pipeline occasionally receives duplicate records from upstream systems, causing the FM to produce repetitive and inaccurate reports. Processing costs scale with record count. Which deduplication approach minimizes cost while maintaining data integrity?
- Configure Amazon Bedrock guardrails to detect and ignore duplicate content in the FM's input prompt at inference time.
- Use a Lambda function to compute a content hash for each record and check it against a DynamoDB table before processing. Skip duplicates and publish duplicate-rate metrics to CloudWatch. — Correct answer
- Add a Glue ETL job that sorts all records and removes consecutive duplicates using a sliding window comparison before FM consumption.
- Store all records including duplicates in S3 and use a nightly Glue Data Quality job to flag duplicates for manual review.
Explanation:
- Why correct: Computing a content hash for each record and checking it against DynamoDB provides O(1) deduplication with high accuracy. Performing the check before processing prevents wasted compute and token costs. Publishing duplicate-rate metrics to CloudWatch enables the team to detect upstream data issues. DynamoDB's low-latency lookups keep the pipeline performant.
- Why A is wrong: Bedrock guardrails operate at the prompt/response level for content filtering — they are not designed to detect duplicate input records across a pipeline. Deduplication should occur before data reaches the FM to avoid unnecessary inference costs.
- Why C is wrong: While Glue ETL can sort and compare records, a sliding window comparison is less accurate than hash-based deduplication (it only catches consecutive duplicates) and adds significant processing overhead for large datasets.
- Why D is wrong: Storing all duplicates and flagging them nightly means duplicate records are processed and sent to the FM before deduplication occurs. This wastes inference costs and manual review adds operational overhead that doesn't scale.
Question 4 — Domain 1: Foundation Model Integration, Data Management, and Compliance (31%)
A development team is building its first RAG application. The team has product manuals stored in Amazon S3 and wants to enable semantic search over these documents using Amazon Bedrock. The team has no prior experience managing vector databases and wants to minimize operational overhead. Which vector store solution should the team use?
- Use Amazon OpenSearch Service with the k-NN plugin. Configure custom HNSW index parameters and manage the cluster scaling and shard allocation.
- Use Amazon Aurora PostgreSQL with the pgvector extension. Store embeddings alongside existing relational data in the same database cluster.
- Use a self-managed FAISS index on Amazon EC2 instances behind an Application Load Balancer for full control over the search algorithm.
- Use Amazon Bedrock Knowledge Bases with a managed vector store. Point the knowledge base at the S3 bucket and let the service handle chunking, embedding, and retrieval. — Correct answer
Explanation:
- Why D is correct: Amazon Bedrock Knowledge Bases is the most operationally efficient choice for a team with no vector database expertise. It provides a fully managed pipeline: automatic document chunking, embedding generation (via Titan Embeddings or other supported models), vector storage, and retrieval, all without requiring infrastructure management. The team points the knowledge base to their S3 bucket and the service handles the rest.
- Why A is wrong: OpenSearch Service with k-NN is a powerful option, but it requires the team to manage cluster sizing, shard configuration, HNSW parameter tuning, and scaling, all of which require vector database expertise the team lacks.
- Why B is wrong: Aurora PostgreSQL with pgvector requires the team to build the embedding generation pipeline, manage index creation (IVFFlat or HNSW), and tune query parameters. It does not provide an integrated end-to-end RAG pipeline.
- Why C is wrong: Self-managed FAISS on EC2 has the highest operational burden, including managing instances, load balancing, index persistence, and scaling. This is the opposite of what a team without vector database expertise should use.
Question 5 — Domain 1: Foundation Model Integration, Data Management, and Compliance (31%)
A developer is building a customer support RAG application using Amazon OpenSearch Service. The knowledge base contains product documentation with exact error codes (e.g., "ERR-4012") and conceptual troubleshooting guides. Users search with both specific error codes and natural language symptom descriptions. Which search architecture should the developer implement?
- Use BM25 keyword search exclusively in OpenSearch to ensure exact error code matches are always returned.
- Use k-NN vector search exclusively with Amazon Titan Embeddings to capture semantic similarity of symptom descriptions.
- Implement hybrid search in OpenSearch combining BM25 keyword matching and k-NN vector search with score normalization and weighted combination. — Correct answer
- Run BM25 and k-NN searches in two separate Lambda functions and return whichever produces more results.
- Use OpenSearch fuzzy matching to handle both error codes and natural language queries in a single text-based search.
Explanation:
- Why C is correct: Hybrid search in OpenSearch combines BM25 keyword matching (which excels at exact matches like error codes) with k-NN vector search (which captures semantic similarity for natural language symptom descriptions). Score normalization ensures fair comparison between the two scoring methods, and weighted combination leverages both strengths.
- Why A is wrong: BM25 keyword search alone would miss semantically related content when users describe symptoms in natural language without using exact error codes or product terminology.
- Why B is wrong: k-NN vector search alone may miss exact error code matches since embeddings represent semantic meaning and may not perfectly distinguish between similar alphanumeric codes like ERR-4012 vs ERR-4013.
- Why D is wrong: Running separate searches in Lambda and returning whichever has more results is not a valid hybrid search strategy. Result count does not indicate relevance, and this approach loses the benefit of combining both scoring signals for unified ranking.
- Why E is wrong: Fuzzy matching handles typos in keyword searches but does not provide semantic understanding. It cannot bridge the gap between a natural language symptom description and the technical terminology used in documentation.
Question 6 — Domain 1: Foundation Model Integration, Data Management, and Compliance (31%)
A healthcare company is building a patient-facing GenAI chatbot on Amazon Bedrock. The chatbot handles sensitive medical inquiries. The security team requires encryption of prompt templates, prevention of prompt injection attacks, content filtering for medical safety, and a full audit trail of all prompt interactions for HIPAA compliance. Which combination of security controls meets ALL of these requirements?
- Encrypt all data with KMS. Implement input validation in Lambda to detect injection patterns. Log all interactions to CloudTrail for a complete audit trail. Skip Guardrails configuration since Lambda-based input validation handles content safety at the application layer.
- Store prompt templates in plaintext on S3 with public read access for developer convenience. Rely on Amazon Bedrock's built-in safety to handle all content filtering without configuring Guardrails. Enable CloudTrail to log API calls for the audit trail.
- Use IAM policies to restrict who can invoke Amazon Bedrock models. Configure Guardrails for content filtering and PII redaction. Store audit logs in CloudWatch Logs. Skip template encryption since the templates themselves do not contain patient data.
- Encrypt prompt templates at rest using AWS KMS. Restrict template access with IAM policies. Configure Amazon Bedrock Guardrails to filter harmful content and redact PII. Enable AWS CloudTrail to log all Bedrock API calls. Implement Lambda-based input validation to detect injection patterns. — Correct answer
- Configure Amazon Bedrock Guardrails with denied topics and PII redaction. Enable CloudTrail for audit logging. Implement Lambda-based input sanitization. Use S3 server-side encryption for templates. Allow all IAM users in the account to invoke prompts to reduce operational overhead.
Explanation:
- Why D is correct: This provides defense in depth. KMS encryption protects templates at rest, IAM restricts access by least privilege, Guardrails provides automated content filtering and PII redaction at the model layer, CloudTrail creates a HIPAA-compliant audit trail, and Lambda-based input validation adds a pre-model defense against prompt injection. Together these cover encryption, access control, content safety, auditability, and injection prevention.
- Why A is wrong: Skipping Guardrails removes the model-layer content filtering that catches harmful outputs the FM might generate. Input validation alone only protects the input side and cannot filter unsafe model responses. For medical safety, content filtering on both inputs and outputs is essential.
- Why B is wrong: Storing templates in plaintext with public access violates encryption and access control requirements. Amazon Bedrock has default safety measures, but explicit Guardrails configuration is necessary for domain-specific requirements like medical safety and PII handling.
- Why C is wrong: Skipping encryption of prompt templates is a security gap, even if templates do not contain patient data directly, they may contain medical context or instructions that should be protected. This approach also lacks input validation, leaving the system vulnerable to prompt injection.
- Why E is wrong: Allowing all IAM users to invoke prompts violates the principle of least privilege. In a HIPAA environment, access must be restricted to only authorized roles. Broad access creates compliance and security risks.
Question 7 — Domain 1: Foundation Model Integration, Data Management, and Compliance (31%)
A media company needs to generate personalized content recommendations in near-real-time based on streaming user interaction data. The system must ingest events, generate embeddings, and make them searchable within seconds. Which data pipeline architecture meets these latency requirements?
- Configure Amazon S3 event notifications to trigger AWS Lambda hourly. Lambda generates embeddings with Amazon Bedrock and updates Amazon OpenSearch Service in batch.
- Use AWS Glue streaming ETL with Apache Spark Structured Streaming. Store processed results in Amazon Redshift for Amazon Bedrock queries.
- Ingest events with Amazon MSK. Run Amazon SageMaker Processing jobs on a 10-minute schedule to generate embeddings. Store vectors in Amazon Aurora with pgvector.
- Ingest events with Amazon Kinesis Data Streams. Use AWS Lambda to process micro-batches. Generate embeddings via Amazon Bedrock. Store and index vectors in Amazon OpenSearch Service for immediate retrieval. — Correct answer
- Route events through Amazon EventBridge Pipes to Amazon SQS. Poll SQS with Lambda at 5-minute intervals. Generate embeddings and store in Amazon DynamoDB.
Explanation:
- Why D is correct: Amazon Kinesis Data Streams captures high-throughput streaming data with sub-second latency. AWS Lambda processes events in micro-batches, keeping latency low without provisioning servers. Amazon Bedrock generates embeddings in near-real-time. Amazon OpenSearch Service stores and indexes vectors for immediate retrieval. This pipeline maintains end-to-end latency suitable for real-time GenAI applications such as live recommendations.
- Why A is wrong: S3 event notifications with hourly Lambda batches introduce up to one hour of delay, which is unacceptable for real-time recommendation use cases.
- Why B is wrong: AWS Glue streaming ETL with Spark Structured Streaming adds processing overhead and latency compared to Lambda. Amazon Redshift is an analytics warehouse and not optimized for low-latency vector similarity search needed for GenAI retrieval.
- Why C is wrong: Amazon MSK is a valid streaming platform, but running SageMaker Processing jobs on a schedule (not continuously) introduces batch delays. Aurora with pgvector supports vector search but is less optimized for high-throughput, low-latency vector indexing at scale compared to OpenSearch.
- Why E is wrong: Polling Amazon SQS at 5-minute intervals introduces significant latency. Amazon DynamoDB does not natively support vector similarity search for embedding-based retrieval.
Question 8 — Domain 2: Implementation and Integration (26%)
A financial services company is building an AI agent using the Strands Agents SDK that must remember prior interactions within a customer session and recall relevant context from previous sessions. The agent handles multi-turn conversations that can span hours. Conversations must survive Lambda cold starts, and the solution must scale to thousands of concurrent sessions. Which memory and state management approach is MOST appropriate?
- Store conversation history in a Python dictionary within the Lambda function's runtime memory. Pass the dictionary between invocations using the function's /tmp directory.
- Persist conversation history and agent state in an Amazon DynamoDB table keyed by session ID. Before each agent turn, retrieve the session record, inject relevant context into the prompt, and summarize older turns to manage token limits. Set a TTL attribute on items to expire stale sessions. — Correct answer
- Write each conversation turn as a JSON object to an Amazon S3 bucket. At the start of every invocation, read the entire conversation file from S3 and pass it to the foundation model as context.
- Use an Amazon ElastiCache for Redis cluster to store session state. Serialize the full conversation history into a Redis hash and retrieve it on each invocation.
Explanation:
- Why correct (B): DynamoDB provides durable, low-latency storage that persists across Lambda cold starts and scales automatically to thousands of concurrent sessions. Keying on session ID enables efficient retrieval of the correct conversation context. Summarizing older turns prevents unbounded token growth in the FM context window while retaining important historical context. A TTL attribute automatically expires stale sessions, reducing storage costs without manual cleanup.
- Why A is wrong: Python dictionaries stored in Lambda memory are ephemeral. They are lost on every cold start, function timeout, or redeployment. With thousands of concurrent sessions, Lambda may spawn many instances, and session state would be stranded on whichever instance originally handled the request. This fails the durability and scalability requirements.
- Why C is wrong: S3 is optimized for large object storage, not low-latency key-value lookups. Reading and writing a full JSON file to S3 for every conversational turn introduces higher latency compared to DynamoDB, and S3 does not support conditional writes natively, creating race conditions if two Lambda invocations handle the same session concurrently.
- Why D is wrong: ElastiCache (Redis) provides low-latency in-memory access but is ephemeral by default. If the cache node is replaced or the cluster scales, data can be lost. It also requires VPC configuration and capacity planning, adding operational complexity. For durable session state that must survive infrastructure changes, a persistent store like DynamoDB is more appropriate.
Question 9 — Domain 2: Implementation and Integration (26%)
A financial services company is deploying a generative AI model that provides investment summaries. The application must maintain 99.9% availability and support rapid rollback if a new model version produces lower-quality outputs. The team uses SageMaker endpoints. Which TWO practices MOST improve deployment reliability for this use case? (Select TWO)
- Configure SageMaker endpoint health checks with automatic instance replacement on failure. — Correct answer
- Deploy new model versions using SageMaker blue/green deployments with automatic rollback triggered by CloudWatch alarms. — Correct answer
- Use a single large instance type to consolidate the workload and simplify management.
- Deploy the model to a single Availability Zone to reduce inter-AZ latency.
- Store model artifacts in a single S3 bucket without versioning to reduce storage costs.
- Run automated load tests against the endpoint before each deployment to validate performance under expected traffic patterns.
Explanation:
- Why A is correct: Health checks with automatic instance replacement ensure that failed instances are detected and replaced quickly, which is essential for maintaining 99.9% availability. SageMaker manages this through its endpoint infrastructure.
- Why B is correct: Blue/green deployments allow you to deploy a new model version alongside the existing one and shift traffic gradually. If CloudWatch alarms detect quality degradation (increased error rates or latency), SageMaker can automatically roll back to the previous version, meeting the rapid rollback requirement.
- Why C is wrong: A single large instance creates a single point of failure. For 99.9% availability, multiple instances across Availability Zones are needed to handle instance failures without service interruption.
- Why D is wrong: Single-AZ deployment creates a single point of failure. If that AZ experiences an outage, the entire service becomes unavailable, which cannot meet 99.9% availability.
- Why E is wrong: Without S3 versioning, you cannot quickly retrieve previous model artifacts for rollback. Versioning is essential for supporting the rapid rollback requirement when a new model version produces lower-quality outputs.
- Why F is wrong: Load testing validates capacity but does not provide runtime failure detection or rapid rollback capability. It is a useful pre-deployment practice but does not directly improve the deployment reliability concerns described (health-based recovery and model version rollback).
Question 10 — Domain 2: Implementation and Integration (26%)
A manufacturing company is integrating Bedrock-powered quality inspection into its existing ERP system. The ERP processes thousands of orders per hour and cannot tolerate latency spikes from FM inference calls. Occasionally, Bedrock experiences transient throttling. Which TWO practices BEST improve integration reliability? (Select TWO)
- Implement synchronous API calls from the ERP directly to Bedrock with increased timeout values to absorb throttling delays.
- Implement a circuit breaker pattern using a Lambda function that monitors Bedrock error rates and automatically falls back to cached responses or queues requests when the failure threshold is exceeded. — Correct answer
- Use Amazon SQS to decouple the ERP from the inference pipeline, allowing the ERP to submit inspection requests asynchronously and poll for results, preventing Bedrock throttling from blocking order processing. — Correct answer
- Increase Bedrock provisioned throughput to the maximum available capacity to eliminate any possibility of throttling.
- Deploy a secondary Bedrock endpoint in another Region with Route 53 failover routing to automatically redirect requests during throttling events.
- Configure the ERP system to retry failed Bedrock calls indefinitely with exponential backoff until a successful response is received.
Explanation:
- Why B is correct: The circuit breaker pattern is a proven enterprise integration pattern for handling downstream failures gracefully. When Bedrock experiences throttling, the circuit breaker trips after a threshold, immediately returning cached responses or queuing requests instead of waiting for timeouts. This prevents cascading failures from impacting the ERP system's throughput.
- Why C is correct: Using SQS to decouple the ERP from inference creates loose coupling, a core enterprise connectivity pattern. The ERP submits requests to the queue and continues processing orders without waiting for inference results. A separate consumer processes the queue at a rate Bedrock can handle, preventing throttling from affecting ERP performance.
- Why A is wrong: Synchronous calls with increased timeouts make the problem worse. The ERP would block on each call, and longer timeouts tie up ERP resources during Bedrock throttling, directly causing the latency spikes the scenario needs to avoid.
- Why D is wrong: While provisioned throughput reduces throttling, it cannot eliminate it entirely during burst traffic. It also does not address the architectural coupling problem and is costly. It does not improve resilience to other failure modes beyond throttling.
- Why E is wrong: Bedrock model availability and configuration vary by Region, and Route 53 failover adds DNS propagation delay. This doubles infrastructure cost and introduces cross-Region data transfer complexity without addressing the core coupling issue between the ERP and the inference layer.
- Why F is wrong: Indefinite retries without a circuit breaker can cause retry storms that worsen throttling, consume ERP resources, and create a cascading failure scenario—the opposite of improving reliability.
Question 11 — Domain 2: Implementation and Integration (26%)
A media company needs to process thousands of content summarization requests daily using Amazon Bedrock. Requests arrive in bursts during peak hours and each summarization takes 15-30 seconds. The company wants to decouple request submission from processing to handle load spikes without throttling. Which architecture provides the MOST scalable asynchronous processing?
- Use Amazon API Gateway to accept requests and publish them to an Amazon SNS topic. Subscribe an AWS Lambda function to the topic. Lambda invokes Bedrock and writes results to Amazon S3. Clients poll S3 for results.
- Use Amazon API Gateway to accept requests and send them to an Amazon SQS queue. Configure AWS Lambda to poll the queue with reserved concurrency matching Bedrock's throughput quota. Store results in Amazon DynamoDB. Use Amazon EventBridge to trigger completion notifications. — Correct answer
- Use Amazon API Gateway to invoke AWS Lambda directly with synchronous integration. Lambda calls Bedrock's InvokeModel API and returns the result in the HTTP response. Use Lambda provisioned concurrency to handle traffic bursts.
- Use Amazon API Gateway to accept requests and write them to Amazon Kinesis Data Streams. AWS Lambda processes records from the stream and calls Bedrock. Results are stored in Amazon S3. A second Lambda function polls S3 for completed results and sends notifications.
Explanation:
- Why B is correct: SQS provides durable message buffering that naturally absorbs burst traffic. Lambda's reserved concurrency can be set to match Bedrock's throughput quota, preventing throttling while maximizing utilization. SQS visibility timeout and dead-letter queue handling provide built-in retry and failure isolation. DynamoDB provides low-latency result storage, and EventBridge enables event-driven completion notifications without polling.
- Why A is wrong: SNS is a push-based pub/sub service that delivers messages immediately to subscribers without buffering. It cannot absorb traffic bursts — if the Lambda subscriber is throttled or fails, messages can be lost unless a dead-letter queue is configured separately. SNS does not provide the backpressure needed to protect Bedrock's throughput quota.
- Why C is wrong: Synchronous invocation tightly couples the client to Bedrock processing time. If summarization takes 15-30 seconds, this risks hitting API Gateway's 29-second integration timeout. Provisioned concurrency reduces cold starts but does not limit total concurrent Bedrock calls, so traffic bursts can still exceed Bedrock's quota and cause throttling.
- Why D is wrong: Kinesis Data Streams is optimized for real-time ordered streaming data and charges per shard-hour regardless of usage, making it less cost-effective than SQS for bursty request-response workloads. Polling S3 for completed results adds latency and unnecessary Lambda invocations compared to event-driven notification via EventBridge.
Question 12 — Domain 2: Implementation and Integration (26%)
A technology company wants to build a multi-agent research system where specialized agents handle different tasks: one for web search, one for internal knowledge base queries, and one for database lookups. The agents must handle multi-step reasoning, dynamically decide which tools to use, and the system must intelligently route user queries to the appropriate agent. Which TWO components should the team use together to build and orchestrate these agents? (Select TWO)
- Build a custom orchestration loop in Lambda that sequentially calls Bedrock's InvokeModel API with hardcoded tool-selection logic for each step of the research workflow.
- Use Strands Agents SDK to define each specialized agent with its own tool definitions and reasoning capabilities, allowing the SDK to handle the autonomous agent loop and dynamic tool selection. — Correct answer
- Use Amazon Bedrock Prompt Flows to create a fixed-sequence workflow that routes every query through all data sources in a predetermined order regardless of the query type.
- Use AWS Agent Squad to orchestrate routing between the specialized agents and manage multi-agent collaboration, using its built-in classifier to direct queries to the appropriate agent. — Correct answer
- Use AWS Step Functions with a Map state that invokes all data source agents in parallel for every query, then uses a Choice state to return the first response that completes.
- Use a single Amazon Bedrock agent with action groups for all data sources, relying on a single system prompt to handle tool selection across all research domains.
Explanation:
- Why B is correct: Strands Agents SDK is an open-source framework for building autonomous AI agents that dynamically decide which tools to use based on context. It handles the agent loop (think, act, observe cycle), tool orchestration, and multi-step reasoning with minimal custom code. Each specialized agent can be defined with its own tools and purpose.
- Why D is correct: AWS Agent Squad (formerly Multi-Agent Orchestrator) is designed for routing queries across multiple specialized agents. Its built-in classifier analyzes the query and routes it to the most appropriate agent, and it supports multi-agent collaboration for cross-domain queries. Together with Strands for agent building, this covers both agent creation and orchestration.
- Why A is wrong: Hardcoded tool-selection logic cannot dynamically adapt to different query types. This approach requires extensive custom code for branching logic and is brittle to maintain as new tools or agents are added.
- Why C is wrong: Bedrock Prompt Flows uses a fixed-sequence workflow that cannot dynamically decide which tools to invoke based on context. Running every query through all data sources regardless of relevance wastes resources and does not support autonomous agent behavior.
- Why E is wrong: Invoking all agents in parallel for every query wastes compute resources and increases cost. Returning the first response to complete ignores the possibility that the fastest response is not the most relevant one. This approach cannot handle queries requiring coordination between agents.
- Why F is wrong: A single agent handling all data sources creates a monolithic system that is harder to maintain. Different research domains may require different FM configurations, guardrails, or tool sets, which a single agent cannot differentiate effectively.
Question 13 — Domain 2: Implementation and Integration (26%)
A customer support platform uses a Bedrock Agent that orchestrates multiple tools including knowledge base lookup, order status retrieval, and refund processing. Response times average 15 seconds due to multi-step orchestration. Users report poor experience waiting for complete responses with no feedback. Which architecture BEST provides real-time feedback during agent orchestration?
- Use API Gateway REST API with long polling. The client sends a request and polls every 2 seconds for partial results stored in DynamoDB. Return the complete response when the agent finishes all orchestration steps.
- Use API Gateway WebSocket API to maintain a persistent connection. Invoke the Bedrock Agent with response streaming enabled through Lambda. Stream each orchestration step's output as incremental WebSocket messages to the client. Store conversation history in DynamoDB. — Correct answer
- Use Amazon SQS to queue requests asynchronously. Process requests with Lambda invoking the Bedrock Agent, and store completed results in DynamoDB. Send a push notification via Amazon SNS when the full response is ready for the client to retrieve.
- Use API Gateway HTTP API with a Lambda function URL configured for response streaming. Buffer all agent tool results in memory and send the complete response as a single chunked payload once all orchestration steps finish.
Explanation:
- Why B is correct: API Gateway WebSocket API provides full-duplex, persistent connections ideal for streaming incremental updates during multi-step agent orchestration. Bedrock's streaming API sends orchestration trace events and text chunks as they are generated, so the client receives real-time progress (e.g., 'Looking up your order...' then 'Processing refund...' then the final answer) rather than waiting 15 seconds with no feedback. DynamoDB stores conversation history for context continuity. This directly solves the UX problem described in the scenario.
- Why A is wrong: Long polling with 2-second intervals introduces unnecessary latency between updates and increases API Gateway request costs due to repeated calls. Storing intermediate results in DynamoDB adds write/read overhead for every partial update. This gives a choppy, delayed experience compared to true streaming over WebSocket.
- Why C is wrong: This asynchronous pattern delivers the complete response only after all orchestration finishes. The user still waits the full 15 seconds with no intermediate feedback, then must retrieve the result in a separate call. It does not solve the core UX problem of providing real-time progress during processing.
- Why D is wrong: Buffering all results in memory and sending them as a single chunked payload defeats the purpose of streaming. Even though chunked transfer encoding is used, the user still waits for the entire agent orchestration to complete before receiving any data. True streaming requires sending incremental data as each step produces output.
Question 14 — Domain 3: AI Safety, Security, and Governance (20%)
A financial services company is building a generative AI application on Amazon Bedrock that generates investment summaries for clients. Regulatory requirements mandate defense-in-depth safety controls. Which THREE components should be included to provide comprehensive protection against harmful inputs and outputs? (Select THREE)
- Amazon Comprehend to pre-process and classify user inputs before they reach the foundation model. — Correct answer
- Amazon Bedrock Guardrails configured with content filters, denied topics, and PII redaction at the model invocation layer. — Correct answer
- A single Lambda function that performs all input validation, output filtering, and monitoring in one execution path.
- Lambda functions for post-processing validation of model outputs against business-specific financial compliance rules. — Correct answer
- API Gateway request validators as the sole safety mechanism at the API boundary.
- Amazon CloudWatch with custom metrics to monitor safety violation counts and trigger EventBridge alerts.
Explanation:
- Why A is correct: Amazon Comprehend provides a pre-processing classification layer that analyzes and filters user inputs before they reach the foundation model, implementing the first line of defense as specified in Skill 3.1.4's defense-in-depth architecture.
- Why B is correct: Bedrock Guardrails provides a dedicated, managed safety layer at the model invocation level with content filters, denied topics, and PII redaction — the model-based guardrails component of defense-in-depth.
- Why D is correct: Lambda post-processing functions add a business-specific compliance layer that catches outputs Guardrails may not address, such as financial regulatory requirements. This is the post-processing validation component of defense-in-depth.
- Why C is wrong: Combining all safety logic into a single Lambda function violates the defense-in-depth principle. If that single function fails, is bypassed, or has a bug, no independent layer provides protection. Each safety layer must operate independently.
- Why E is wrong: API Gateway request validators handle schema and parameter validation, not content safety analysis. They cannot assess the semantic meaning of inputs for harmful patterns and should not serve as the sole safety mechanism.
- Why F is wrong: CloudWatch monitoring and alerting provide observability into safety events but do not actively prevent harmful content. Monitoring detects and reports violations after they occur rather than blocking them in real time.
Question 15 — Domain 3: AI Safety, Security, and Governance (20%)
A financial services company is deploying a Bedrock-based customer advisor chatbot. Regulations require that customer account numbers, SSNs, and credit card numbers never appear in model responses, even if customers provide them in prompts. Names may appear but should be masked. Which approach meets these requirements with the least operational overhead?
- Create a Bedrock Guardrail with sensitive information filters that sets SSN, credit card, and account number PII types to BLOCK and name PII types to ANONYMIZE, then apply the guardrail to both input and output of the Bedrock model invocation. — Correct answer
- Add a system prompt instructing the model to never repeat financial PII, and log all conversations to CloudWatch Logs for post-hoc manual review of compliance.
- Deploy AWS WAF rules on the API Gateway in front of the application to pattern-match and block any request or response containing SSN or credit card regex patterns.
- Use Amazon Comprehend as a post-processing step that scans model outputs and returns an error to the user if PII is detected, requiring them to rephrase their question.
- Configure S3 Object Lock in Compliance mode on the conversation log bucket to ensure PII data cannot be modified or deleted, maintaining an immutable audit trail.
Explanation:
- Why A is correct: Bedrock Guardrails sensitive information filters natively support configurable PII entity types (SSN, credit card, account number, etc.) with per-type actions. Setting high-sensitivity types to BLOCK prevents them from appearing in responses, while setting lower-sensitivity types to ANONYMIZE replaces them with placeholders, maintaining conversational flow. Applying the guardrail to both input and output provides defense-in-depth.
- Why B is wrong: System prompts are advisory, not enforceable—the model may still include PII in responses. Manual CloudWatch review is reactive and cannot prevent PII exposure in real time.
- Why C is wrong: AWS WAF operates at the HTTP request layer and can only block or allow entire requests. It cannot selectively filter PII from within Bedrock model responses. Blocking any request with financial data patterns would reject legitimate customer inquiries.
- Why D is wrong: Returning an error after PII is detected in the output means the PII was already generated by the model. This creates a poor user experience and does not prevent PII from being produced. Guardrails can mask inline without disrupting the conversation.
- Why E is wrong: S3 Object Lock addresses data immutability for audit logs, not real-time PII filtering during model interactions. It solves a different problem entirely.
Question 16 — Domain 3: AI Safety, Security, and Governance (20%)
A healthcare company uses multiple data sources (EHR systems, clinical notes, research databases) to fine-tune a foundation model. Auditors require end-to-end traceability showing how each data source was transformed before being used in training. Which approach provides the most defensible data lineage for audit purposes?
- Store all raw data in a single S3 bucket with prefix-based organization and rely on S3 access logs to reconstruct the data flow.
- Use AWS Glue crawlers and the Glue Data Catalog to register all source datasets with metadata tags for source attribution, and use Glue ETL jobs with lineage tracking to document each transformation step. — Correct answer
- Use Amazon Athena to query all source databases directly at training time, eliminating the need for transformation tracking.
- Create a spreadsheet listing all data sources and manually update it each time a new dataset is added or a transformation changes.
Explanation:
- Why B is correct: AWS Glue provides automated data lineage through crawlers (which discover and catalog data sources), Data Catalog (which maintains metadata with source attribution tags), and ETL jobs (which track transformations). This creates an auditable, automated lineage trail from raw sources through transformation to training-ready datasets.
- Why A is wrong: S3 access logs capture who accessed files and when, but do not track data transformations, schema changes, or the logical flow from source to training-ready datasets. Prefix-based organization provides no transformation lineage.
- Why C is wrong: Querying sources directly does not eliminate transformations — data still requires cleaning, normalization, and deidentification. Direct queries provide no lineage documentation and create reproducibility challenges.
- Why D is wrong: Manual spreadsheets are not auditable, not programmatically queryable, prone to human error, and cannot scale with frequent pipeline changes — making them indefensible in a regulatory audit.
Question 17 — Domain 3: AI Safety, Security, and Governance (20%)
A financial services company built an Amazon Bedrock agent that researches market data, queries internal databases, and generates investment summaries. Compliance requires that every recommendation be fully auditable — showing what data sources were consulted, what reasoning led to the conclusion, and what tools the agent invoked. Which approach provides the MOST comprehensive audit trail?
- Store the final generated investment summary in Amazon DynamoDB with a timestamp, and require analysts to manually document the reasoning behind each recommendation.
- Enable Amazon CloudWatch Logs for the Bedrock agent and parse the log entries to reconstruct the agent's decision flow after the fact.
- Enable Amazon Bedrock agent tracing to capture the full reasoning trace — including thought processes, tool invocations, knowledge base queries, and intermediate outputs — and store traces in Amazon S3 for compliance review. — Correct answer
- Implement a custom middleware layer using AWS Lambda that intercepts all API calls between the agent and external services, logging each request and response independently.
Explanation:
- Why C is correct: Amazon Bedrock agent tracing is purpose-built for this use case. When enabled, it captures the agent's complete reasoning chain: the rationale text (chain-of-thought), each action group invocation, knowledge base retrieval results with source documents and S3 locations, and observation steps. This provides a native, structured audit trail showing exactly what data was consulted, what tools were called, and how the agent arrived at its recommendation — directly satisfying the compliance requirement for full auditability.
- Why A is wrong: Storing only the final output loses all intermediate reasoning and data source information. Manual documentation is error-prone, not scalable, and cannot capture the actual machine reasoning process.
- Why B is wrong: While CloudWatch Logs can capture Bedrock API invocations, standard log entries do not include the agent's internal reasoning steps, thought processes, or the structured trace of tool invocations and observations. Reconstructing the decision flow from raw logs is incomplete and unreliable compared to native tracing.
- Why D is wrong: A custom Lambda middleware would only capture external API calls, missing the agent's internal reasoning and orchestration logic. This adds significant development overhead and still cannot capture the agent's thought process or how it decided which tools to invoke.
Question 18 — Domain 3: AI Safety, Security, and Governance (20%)
A retail company uses Amazon Bedrock to generate personalized product descriptions for its e-commerce platform. During quality audits, reviewers discover that the FM occasionally produces descriptions containing inappropriate language, fabricated product certifications (such as non-existent safety ratings), and references to competitor products. The company needs a content safety framework that prevents these harmful outputs while minimizing impact on description generation throughput. Which approach MOST effectively addresses all three output issues?
- Implement a post-processing Lambda function that uses Amazon Comprehend to detect toxicity in FM outputs. Reject any response with toxicity scores above a defined threshold and regenerate the description automatically.
- Configure Amazon Bedrock Guardrails with content filters set to block toxic and inappropriate language, denied topic policies to prevent competitor product references, and word filters for specific prohibited terms including fabricated certification names. Apply the guardrail to the Bedrock InvokeModel API to filter outputs before they reach the application. — Correct answer
- Fine-tune the FM on a curated dataset of approved product descriptions to reduce the probability of generating inappropriate or off-topic content. Schedule periodic retraining as new product lines are added.
- Deploy a separate content moderation FM that reviews every generated product description against company content policies before publishing. Route flagged descriptions to a human review queue.
- Add comprehensive system prompt instructions specifying content policies including prohibited language categories, certification accuracy requirements, and competitor mention restrictions. Increase the system prompt token allocation to ensure all policies are clearly communicated to the FM.
Explanation:
- Why B is correct: Amazon Bedrock Guardrails provides a managed, multi-layered output filtering framework that addresses all three identified issues: content filters with configurable strength thresholds detect and block toxic or inappropriate language; denied topic policies prevent the FM from generating content about competitor products by evaluating semantic meaning rather than just keywords; and word filters block specific prohibited terms such as fabricated certification names. Guardrails are evaluated inline with the InvokeModel API call with minimal latency impact, maintaining generation throughput. This directly implements Skill 3.1.2's emphasis on using Amazon Bedrock Guardrails to filter responses for content safety.
- Why A is wrong: Amazon Comprehend toxicity detection can flag inappropriate language, but it cannot detect competitor references or fabricated product certifications — these require semantic topic detection, not toxicity scoring. Rejecting and regenerating descriptions wastes compute, increases latency, and reduces throughput without guaranteeing the regenerated output will be compliant. This approach also addresses only one of the three identified issues.
- Why C is wrong: Fine-tuning reduces but does not eliminate problematic outputs — the FM can still generate inappropriate content, especially for novel product categories not well represented in the training data. Fine-tuning requires significant compute resources and time, cannot enforce hard boundaries on prohibited topics, and does not provide the deterministic output filtering needed for content safety. Each retraining cycle introduces regression risk, and the approach addresses probabilities rather than guarantees.
- Why D is wrong: Running every description through a second FM doubles inference costs and introduces significant latency, directly impacting the throughput requirement. The moderation FM could itself make incorrect compliance judgments or hallucinate compliance assessments. Human review queues create bottlenecks that do not scale with high-volume product catalog updates, contradicting the throughput requirement.
- Why E is wrong: System prompt instructions are advisory, not enforceable — the FM may not consistently follow all policy rules, especially as the policy list grows longer. Research shows that very long system prompts can degrade model performance on the primary task. System prompts provide no guaranteed output filtering mechanism and cannot deterministically prevent prohibited content from appearing in generated descriptions.
Question 19 — Domain 4: Operational Efficiency and Optimization (12%)
A company's Amazon Bedrock costs have increased 300% over the past quarter due to growing adoption across business units. The CTO requires a 40% cost reduction without degrading user-perceived response quality. Which three strategies would provide the MOST significant cost reduction? (Select THREE)
- Implement semantic caching using vector similarity to serve cached responses for queries that are semantically similar to previous requests, bypassing FM invocation entirely. — Correct answer
- Migrate all workloads from On-Demand to Provisioned Throughput regardless of traffic patterns to lock in lower per-token pricing.
- Route requests through a complexity classifier that directs simple queries to smaller, less expensive models and reserves larger models for complex reasoning tasks. — Correct answer
- Increase the max_tokens parameter across all applications to ensure complete responses and reduce the need for follow-up queries.
- Compress prompts by summarizing lengthy context, removing redundant instructions, and using concise phrasing to reduce input token counts. — Correct answer
- Disable CloudWatch model invocation logging to eliminate the overhead associated with metrics collection and reduce operational costs.
Explanation:
- Why A is correct: Semantic caching uses vector similarity to identify queries that are semantically equivalent to previously answered questions and returns cached responses, completely avoiding FM invocation costs for repeat or near-repeat queries. In high-traffic applications, cache hit rates of 30-60% are common, directly reducing Bedrock API costs.
- Why C is correct: A complexity-based router directs simple requests (greetings, FAQs) to smaller, cheaper models like Claude Haiku while reserving larger models for complex reasoning tasks. Since simple queries often represent the majority of traffic, this can reduce costs by 40-60% with minimal quality impact.
- Why E is correct: Prompt compression through summarizing verbose context, removing redundant instructions, and using concise phrasing directly reduces input token counts, which are a primary cost driver in FM pricing. This is especially effective for applications with large system prompts or extensive context.
- Why B is wrong: Migrating all workloads to Provisioned Throughput regardless of traffic patterns would result in paying for unused capacity during low-traffic periods. Provisioned Throughput is only cost-effective when utilization is consistently high. Variable or unpredictable workloads benefit from On-Demand pricing.
- Why D is wrong: Increasing max_tokens generates longer responses, which increases output token costs. While complete responses may reduce follow-up queries, the net effect is higher per-request cost, not lower.
- Why F is wrong: Disabling CloudWatch model invocation logging removes cost visibility and monitoring capability. Logging overhead is negligible compared to FM invocation costs, and without logging you lose the ability to identify optimization opportunities.
Question 20 — Domain 4: Operational Efficiency and Optimization (12%)
A company's GenAI chatbot runs on AWS Lambda and experiences 5-8 second cold starts when traffic spikes after business hours. The chatbot must respond within 2 seconds, and it handles approximately 500 concurrent requests during peak periods. The application is written in Python with several large ML preprocessing libraries.
Which approach MOST effectively addresses the cold start issue?
- Increase Lambda memory to 10 GB to speed up initialization and reduce cold start duration.
- Package all dependencies into a single deployment ZIP file to simplify the initialization process.
- Configure Lambda provisioned concurrency to match peak demand and move shared libraries into Lambda layers to reduce package size. — Correct answer
- Migrate from Lambda to Amazon ECS with AWS Fargate to eliminate Lambda cold starts entirely.
- Enable Lambda SnapStart and create a CloudWatch Events rule to invoke the function every 5 minutes as a keep-warm mechanism.
Explanation:
- Why C is correct: Lambda provisioned concurrency keeps a specified number of execution environments initialized and ready, eliminating cold starts for those environments. Setting it to match peak demand (500) ensures consistent sub-2-second response times. Moving large shared libraries into Lambda layers reduces the deployment package size, which speeds up any remaining initialization.
- Why A is wrong: Increasing Lambda memory does proportionally increase CPU allocation, which can speed up initialization, but it does not eliminate cold starts. The 5-8 second cold starts are caused by environment initialization, not insufficient compute during a warm invocation.
- Why B is wrong: Packaging all dependencies into a single ZIP makes the deployment package larger, which increases cold start time rather than reducing it. Separating dependencies into layers is the better approach.
- Why D is wrong: Migrating to ECS with Fargate eliminates Lambda cold starts but introduces Fargate's own cold start latency (typically 30-60 seconds for new tasks). It also adds operational complexity without a clear advantage for this event-driven chatbot pattern.
- Why E is wrong: Lambda SnapStart is only available for Java runtimes (using Corretto). Since this application is written in Python, SnapStart cannot be used. A CloudWatch Events keep-warm approach only maintains a single warm instance, which does not scale to 500 concurrent requests.
Question 21 — Domain 4: Operational Efficiency and Optimization (12%)
A company operates a RAG application backed by Amazon OpenSearch Serverless and Amazon Bedrock. Over the past two weeks, users report that answer quality has declined, but end-to-end response latency remains unchanged. The team needs to pinpoint where quality is degrading. Which monitoring approach is MOST effective?
- Enable CloudWatch Anomaly Detection on the Bedrock ModelLatency metric to identify when the model takes longer to generate responses, since increased latency correlates with quality degradation.
- Instrument the RAG pipeline to emit custom CloudWatch metrics at each stage — retrieval relevance scores, grounding accuracy, and generation quality scores. Build a time-series dashboard showing per-stage quality trends to isolate the degrading component. — Correct answer
- Increase the top-k retrieval parameter in OpenSearch to return more documents per query, which will improve answer quality without requiring additional monitoring.
- Monitor the OpenSearch Serverless OCU utilization and search latency metrics in CloudWatch, and scale up OCUs when utilization exceeds 80 percent.
Explanation:
- Why B is correct: Since latency is unchanged but quality is declining, the issue lies in the quality of retrieval or generation — not performance. Per-stage quality metrics (retrieval relevance scores, grounding accuracy, generation quality) let the team see exactly which stage is degrading over time. A time-series dashboard reveals trends such as declining relevance scores from OpenSearch (indicating stale embeddings or index drift) versus declining generation quality (indicating a model issue). This directly addresses Skill 4.3.5 (vector store performance monitoring and data quality validation) and Skill 4.3.2 (response quality tracking).
- Why A is wrong: The scenario states latency is unchanged, so anomaly detection on ModelLatency would not flag anything. Latency and quality are independent dimensions — a model can respond quickly with poor answers. This approach monitors the wrong signal.
- Why C is wrong: Blindly increasing top-k is a remediation guess, not a monitoring approach. Without metrics showing that retrieval relevance is the issue, increasing top-k could introduce more noise and actually worsen quality. The question asks for monitoring, not tuning.
- Why D is wrong: OCU utilization and search latency are infrastructure performance metrics. They would help if queries were slow or timing out, but the scenario specifies latency is unchanged. The quality problem may be in embedding staleness or relevance scoring, which OCU metrics do not capture.
Question 22 — Domain 4: Operational Efficiency and Optimization (12%)
A development team's GenAI application sends customer support transcripts averaging 15,000 tokens to Amazon Bedrock for sentiment analysis. Many transcripts contain repeated greetings, email signatures, and boilerplate disclaimers. The team wants to reduce token costs while maintaining analysis accuracy. Which TWO actions will most effectively reduce token usage? (Select TWO)
- Implement prompt compression to strip boilerplate sections, email signatures, and redundant content before sending transcripts to the FM. — Correct answer
- Switch from a text-based FM to a multimodal FM to process the transcripts as scanned images, which uses fewer input tokens.
- Set the max_tokens response parameter to 50 to limit output token costs regardless of query complexity.
- Increase the temperature parameter to produce more concise and shorter FM responses.
- Apply context pruning to extract only the customer-agent dialogue portions relevant to sentiment, removing system-generated headers and routing metadata. — Correct answer
Explanation:
- Why A is correct: Prompt compression removes boilerplate text (greetings, signatures, disclaimers) that adds tokens without contributing to analysis accuracy. Stripping this content from 15,000-token transcripts can significantly reduce input token costs while preserving the meaningful dialogue content the FM needs for accurate sentiment analysis.
- Why E is correct: Context pruning extracts only the relevant customer-agent dialogue, removing system metadata, routing headers, and auto-generated content. This directly reduces the input token count by eliminating content that does not contribute to sentiment analysis, lowering costs while maintaining or even improving accuracy by reducing noise.
- Why B is wrong: Converting text transcripts to images for a multimodal FM would not reduce token costs — image processing typically costs more per input than text, and the FM would still need to extract text content from the image. This adds complexity and cost rather than reducing it.
- Why C is wrong: Reducing max_tokens to 50 limits output tokens only, not input tokens. Since the main cost driver is the 15,000-token input transcripts, this addresses the smaller portion of the cost. It may also truncate sentiment analysis results, degrading quality.
- Why D is wrong: Temperature controls randomness in token sampling, not response length. Increasing temperature makes responses more varied, not shorter. It has no meaningful effect on token cost reduction.
Question 23 — Domain 5: Testing, Validation, and Troubleshooting (11%)
A team is migrating from a traditional ML text classification model to a foundation model (FM) on Amazon Bedrock for generating customer response summaries. Their current evaluation relies on precision, recall, and F1 score. The team needs to establish an evaluation framework appropriate for generative AI outputs. Which approach should the team take?
- Use BLEU and ROUGE scores as the primary evaluation metrics, since they are industry-standard NLP benchmarks that reliably measure text generation quality.
- Develop an assessment framework that measures relevance, factual accuracy, fluency, and consistency of generated outputs, supplemented by human evaluation for subjective quality. — Correct answer
- Measure model perplexity on a held-out test set, since lower perplexity directly correlates with higher output quality for all use cases.
- Replace all automated metrics with a human evaluation panel, since only human reviewers can assess generative AI output quality.
Explanation:
- Why B is correct: Traditional ML metrics like precision, recall, and F1 measure classification correctness but do not capture the nuanced qualities of generated text. For FM-based text generation, the team needs metrics that assess relevance (is the output pertinent to the query?), factual accuracy (are the claims correct?), fluency (is the language natural and grammatically correct?), and consistency (does the model produce similar quality across runs?). These dimensions go beyond what precision/recall can measure and are specifically designed for evaluating generative outputs.
- Why A is wrong: BLEU and ROUGE measure n-gram overlap between generated text and reference text. While useful for translation and summarization, they are surface-level metrics that do not assess factual accuracy, relevance to the original query, or logical consistency. They are insufficient as the primary evaluation framework for generative AI.
- Why C is wrong: Perplexity measures how well a language model predicts text and is useful during model training. However, low perplexity does not guarantee that outputs are relevant, factually accurate, or useful for the business use case. It is a model-centric metric, not an output quality metric.
- Why D is wrong: While human evaluation is valuable, relying solely on human reviewers without any automated metrics creates a bottleneck that does not scale. A comprehensive framework should combine automated metrics (relevance, accuracy, fluency, consistency) with human evaluation, not replace one with the other.
Question 24 — Domain 5: Testing, Validation, and Troubleshooting (11%)
A machine learning team updated their prompt template for a customer support chatbot on Amazon Bedrock, but response quality has degraded compared to the previous version. The team wants to systematically identify what caused the regression. Which TWO troubleshooting actions are most effective? (Select TWO)
- Increase the model's temperature parameter to generate more varied responses for comparison
- Switch to a larger foundation model to compensate for the prompt quality issues
- Run both prompt versions against a standardized test suite of representative inputs and compare outputs using evaluation metrics such as relevance, accuracy, and tone — Correct answer
- Remove all system instructions and rely on the model's default behavior to establish a baseline
- Use A/B testing with a controlled subset of production traffic to measure quality metrics between the old and new prompt versions — Correct answer
Explanation:
- Why C is correct: A standardized test suite with evaluation metrics provides a controlled, reproducible comparison between prompt versions. By testing with the same inputs, the team can isolate which specific changes caused the regression — whether it's a particular question type, tone, or edge case — and pinpoint the exact prompt modifications responsible.
- Why E is correct: A/B testing with real production traffic captures quality differences under actual usage conditions that a test suite alone may miss. By measuring metrics like accuracy, user satisfaction, and escalation rates between both versions with a controlled user subset, the team gets data-driven evidence of the regression's scope and impact.
- Why A is wrong: Increasing temperature introduces more randomness in outputs, which makes systematic comparison harder and doesn't diagnose why the prompt change degraded quality. It masks or worsens prompt issues.
- Why B is wrong: Switching to a larger model doesn't diagnose the prompt regression — it compensates with more model capability rather than identifying and fixing the prompt problem.
- Why D is wrong: Removing all system instructions eliminates the prompt engineering entirely, destroying the intended behavior. This makes outputs unpredictable rather than diagnosing the issue.
Question 25 — Domain 5: Testing, Validation, and Troubleshooting (11%)
A company is deploying a generative AI application on Amazon Bedrock and needs to determine which foundation model offers the best balance of quality and cost for their document summarization use case. They must evaluate multiple candidate models systematically before making a production selection. Which approach should the team use?
- Deploy each candidate model to production sequentially, monitor user complaints for two weeks per model, and select the model with the fewest complaints.
- Use Amazon Bedrock Model Evaluation jobs to run the same curated test dataset across all candidate models, comparing quality metrics such as accuracy and robustness alongside token usage and latency for each model. — Correct answer
- Select the model with the lowest per-token price, since summarization quality is comparable across all foundation models available in Bedrock.
- Choose the model with the largest parameter count, as larger models always produce higher-quality summaries regardless of the specific use case.
- Run each model with a single sample document and select whichever model produces the output that the team lead subjectively prefers.
Explanation:
- Why B is correct: Amazon Bedrock Model Evaluation jobs allow you to run systematic evaluations using curated datasets with automatic scoring across multiple models. This enables objective comparison of quality metrics (accuracy, robustness, toxicity) alongside operational metrics (latency, token consumption, cost per request). This data-driven approach directly supports the cost-performance analysis and multi-model evaluation described in Skill 5.1.2.
- Why A is wrong: Deploying each model to production sequentially is slow, expensive, and risky. It exposes real users to untested models and relies on complaints — a lagging indicator — rather than systematic measurement. Subtle quality differences may go unreported.
- Why C is wrong: The lowest per-token price does not guarantee acceptable summarization quality. A cheaper model may miss key points or introduce inaccuracies. Optimal model selection requires analyzing the cost-quality trade-off with actual evaluation data, not price alone.
- Why D is wrong: Larger parameter counts do not guarantee better output for a specific task. A smaller, well-suited model may outperform a larger general-purpose model on summarization while costing less. Model selection should be driven by evaluation data, not parameter size.
- Why E is wrong: A single sample document is statistically meaningless, and one person's subjective preference introduces bias. Systematic evaluation requires diverse test inputs and objective metrics to identify consistent performance across a range of scenarios.
Question 26 — Mixed (RAG at Scale)
A healthcare company is building a RAG system to search across medical research papers (PDFs), clinical trial reports (DOCX), and drug interaction databases (HTML tables). Initial testing shows poor retrieval accuracy, with the FM frequently generating responses based on garbled or incomplete text. Which THREE preprocessing steps should the team prioritize to improve embedding quality? (Select THREE)
- Implement format-specific text extraction using Amazon Textract for PDFs, python-docx for DOCX files, and HTML parsers for web content, preserving table structures. — Correct answer
- Apply text normalization including removing headers and footers, standardizing medical abbreviations, and deduplicating repeated content across document versions. — Correct answer
- Use semantic chunking that splits documents at section boundaries (Methods, Results, Discussion) with 10-15% overlap between chunks. — Correct answer
- Convert all documents to plain text using a single generic parser to standardize the pipeline and reduce preprocessing complexity.
- Set a fixed chunk size of 4,096 tokens to maximize the context provided to the embedding model per chunk.
- Skip text extraction for HTML documents and embed the raw HTML markup directly, since embedding models can interpret HTML tags.
Explanation:
- Why A is correct: Different document formats require specialized extraction. Amazon Textract handles complex PDF layouts including tables and forms. Format-specific parsers preserve structural elements that a generic approach would lose, directly improving the quality of text fed to embedding models.
- Why B is correct: Text normalization removes noise (headers, footers, page numbers) that pollutes embeddings. Standardizing medical abbreviations ensures consistent vector representations, and deduplication prevents the same content from dominating search results.
- Why C is correct: Semantic chunking at logical section boundaries preserves the contextual integrity of medical content. Overlap between chunks ensures that information near boundaries is not lost, which is critical for medical texts where findings reference prior methodology.
- Why D is wrong: A generic parser cannot handle complex PDF layouts with tables, multi-column text, or embedded images. Medical PDFs in particular often have specialized formatting that generic extraction garbles, which is the exact problem described in the scenario.
- Why E is wrong: Fixed 4,096-token chunks are excessively large for most embedding models and mix unrelated content within a single chunk, reducing retrieval precision. Smaller, semantically meaningful chunks produce better embeddings.
- Why F is wrong: Raw HTML markup (tags, attributes, CSS classes) adds noise to embeddings without semantic value. The embedding model processes HTML tags as text, diluting the actual content signal and reducing retrieval accuracy.
Question 27 — Mixed (Agents + Workflows)
A company's Bedrock Agent handles 50,000 daily customer inquiries. Analysis shows that 40% of invocations ask the same 200 frequently asked questions, and the agent averages 3.2 tool calls per invocation when only 1.8 are typically needed. The team must reduce FM invocation costs without degrading response quality. Which TWO approaches provide the most significant cost reduction? (Select TWO)
- Switch from on-demand to provisioned throughput for the foundation model.
- Implement a semantic cache using Amazon ElastiCache and Amazon Bedrock embeddings to serve cached responses for similar queries before invoking the agent. — Correct answer
- Reduce the agent's maximum iteration count to 1 to limit tool calls.
- Refine action group descriptions and the agent's system prompt to improve tool selection accuracy, reducing unnecessary tool invocations. — Correct answer
- Migrate from Bedrock Agents to direct InvokeModel API calls for all interactions.
Explanation:
- Why B is correct: With 40% of queries being repetitive FAQs, a semantic cache intercepts these before they reach the agent, eliminating FM invocations entirely for cached responses. This directly addresses the largest source of redundant costs.
- Why D is correct: The gap between 3.2 actual and 1.8 needed tool calls indicates poor tool selection. Improving action group descriptions and the system prompt helps the FM reason better about which tools to use, reducing unnecessary invocations by approximately 44%.
- Why A is wrong: Provisioned throughput reduces per-token cost for sustained load but does not reduce the number of invocations. The problem is redundant invocations, not per-token pricing.
- Why C is wrong: Limiting iterations to 1 would prevent the agent from completing multi-step tasks that legitimately require multiple tool calls, severely degrading response quality.
- Why E is wrong: Direct InvokeModel calls lose all agent orchestration capabilities (tool use, reasoning, knowledge base integration), requiring the company to rebuild this logic from scratch — increasing development cost, not reducing it.
Question 28 — Mixed (Enterprise Integration)
A company is building an event-driven GenAI content pipeline. When a document is uploaded to Amazon S3, it must be processed by three independent services: a Bedrock-powered summarization service, a translation service, and a compliance review service. Each service scales independently and has different processing times. Which event routing design best supports this architecture?
- Use Amazon SNS with a single topic and subscribe all three processing services directly, relying on message filtering policies to route document types.
- Implement direct Lambda invocations from the S3 event handler to each processing service sequentially, using AWS Step Functions for orchestration and retry logic.
- Create an EventBridge bus with content-based rules that route events to each service's Amazon SQS queue based on document metadata. Configure dead-letter queues for failed deliveries and enable event replay for reprocessing. — Correct answer
- Create separate EventBridge buses for each processing service with cross-bus event forwarding rules, letting each service manage its own event filtering independently.
- Use Amazon Kinesis Data Streams with a single shard to ensure ordered processing across all three services, with each service maintaining its own checkpoint position.
Explanation:
- Why correct: A single EventBridge bus with content-based rules provides centralized event management while routing events to each service based on document metadata (file type, language, compliance tier). Targeting each service's SQS queue decouples producers from consumers, allowing independent scaling and processing at each service's own pace. Dead-letter queues capture failed deliveries without losing events. Event replay enables reprocessing if a consumer was temporarily unavailable or a bug was fixed.
- Why A is wrong: SNS fan-out works for simple broadcast but lacks EventBridge's content-based routing sophistication, event replay capability, and schema validation. SNS message filtering is less expressive than EventBridge rules for complex document metadata patterns.
- Why B is wrong: Sequential Lambda invocations via Step Functions create tight coupling between services. If one service is slow or fails, it blocks the entire pipeline, contradicting the requirement for independent scaling.
- Why D is wrong: Separate EventBridge buses per service adds operational complexity without benefit when all events originate from the same source. Cross-bus forwarding introduces additional latency and failure points. A single bus with multiple rules is simpler and achieves the same routing.
- Why E is wrong: Kinesis Data Streams with a single shard limits throughput and forces ordered processing, which is unnecessary when the three services are independent. Each service must manage its own shard iterator, adding complexity without benefit.
Question 29 — Mixed (Cost/Perf/Observability)
A company wants to implement performance baselines for GenAI. Which baseline approach enables optimization?
- Static baselines without updates.
- No performance targets.
- No deviation monitoring.
- Establish baselines for key metrics. Monitor deviations from baselines. Set performance targets. Track improvements over time. Compare against industry benchmarks. Regular baseline reviews and updates. — Correct answer
- No baseline establishment.
Explanation:
- Why correct: Baselines enable comparison. Deviation monitoring identifies issues. Targets guide optimization. Time-series tracking shows progress. Benchmark comparison provides context. Regular reviews maintain relevance. This enables effective performance management.
- Why A is wrong: Baselines enable performance comparison.
- Why B is wrong: Regular updates maintain baseline relevance.
- Why C is wrong: Deviation monitoring identifies performance issues.
- Why E is wrong: Targets guide optimization efforts.
Question 30 — Mixed Review (Domains 1–5)
A company is deploying an updated prompt template and Guardrails configuration for its Amazon Bedrock-based summarization service. The service handles 50,000 requests per hour in production. The team needs to validate that the new prompt does not increase hallucination rates or trigger unexpected Guardrails blocks before full rollout. Which deployment strategy minimizes risk while enabling rapid rollback?
- Use a blue/green deployment with AWS CodeDeploy. Deploy the new configuration to the green environment, run a manual approval gate for 30 minutes, then switch all traffic from blue to green.
- Use a rolling deployment strategy with AWS CodePipeline. Update each Lambda function sequentially and monitor CloudWatch logs for errors after each update completes.
- Use a canary deployment with Lambda weighted aliases managed by AWS CodeDeploy. Route 5% of traffic to the new version, configure CloudWatch alarms on Guardrails block rate and evaluation metrics, and set automatic rollback if alarms trigger. — Correct answer
- Deploy the new configuration to a staging environment first, run automated tests with synthetic data, then deploy directly to production after tests pass.
- Use feature flags in the application code to gradually enable the new prompt for a percentage of users. Monitor application logs and manually disable the flag if issues arise.
Explanation:
- Why correct (C): A canary deployment using Lambda weighted aliases routes a small percentage of traffic (e.g., 5%) to the new version while the majority continues on the stable version. CloudWatch alarms on Guardrails block rates and hallucination metrics (from automated evaluation) act as deployment gates — if the new version's block rate spikes or quality degrades, CodeDeploy automatically shifts all traffic back to the stable version. This approach validates the change under real production traffic without risking the full user base.
- Why A is wrong: Blue/green with a manual approval gate requires a human to review and approve the switch. At 50,000 requests/hour, even a short delay in noticing a problem during the green environment's full-traffic test could affect thousands of users. It also lacks the gradual traffic shift that limits blast radius.
- Why B is wrong: Rolling deployments update instances sequentially. For a Lambda-based Bedrock service, this doesn't apply naturally — Lambda versions are immutable. Even if using containers, rolling updates don't allow fine-grained traffic percentage control or automatic rollback based on custom metrics.
- Why D is wrong: Testing in a staging environment with synthetic data is a good practice but insufficient on its own. Synthetic data may not capture the full diversity of production inputs, so hallucination or Guardrails issues triggered by real user queries could go undetected until full production deployment.
- Why E is wrong: Feature flags provide application-level control but add complexity to the codebase. They don't integrate natively with CloudWatch alarms for automatic rollback — the team would need to build custom logic to flip the flag on metric breaches, which is what CodeDeploy already provides natively with canary deployments.
JavaScript is required to use this application.
Please enable JavaScript in your browser to access the full NestedCerts platform.
Contact: support@nestedcerts.com