Free AIP-C01 Practice Test

This solution provides a complete, serverless, and automated canary deployment orchestration. Using Amazon Bedrock with provisioned throughput is suitable for a production API requiring consistent performance. AWS Step Functions is the ideal service for managing a stateful, multi-step workflow like a canary deployment. It can natively handle shifting traffic, waiting for a defined period, and executing conditional logic. An AWS Lambda function can query Amazon CloudWatch metrics (latency, errors). The Step Functions workflow can then automatically decide whether to increase traffic or initiate a rollback based on these metrics, meeting the requirement for a fully automated process without manual intervention.

B. This option relies on vague "external logic" for automation and rollback, making it less integrated and robust than a Step Functions-based orchestration.
C. Using Amazon SageMaker endpoints as a proxy for Bedrock models adds unnecessary complexity and is not the most direct or efficient architecture.
D. This proposes an unconventional architecture; AWS Systems Manager is not the standard tool for orchestrating application-level canary deployments.

1. AWS Step Functions Developer Guide, "Use Cases". The documentation explicitly lists "perform canary deployments" as a primary use case for Step Functions, highlighting its ability to orchestrate complex, stateful deployment workflows.

2. AWS Compute Blog, "Implementing canary deployments of serverless applications with AWS SAM and CodeDeploy". This article demonstrates the pattern of using a state machine (like Step Functions) to control gradual traffic shifting and automated rollbacks based on alarms.

3. Amazon Bedrock User Guide, "Provisioned Throughput". This section explains that Provisioned Throughput is designed for "large-scale and mission-critical applications" that require guaranteed latency and throughput, justifying its use in a payment processing API.

This solution effectively meets all requirements. Using parallel processing for the different Amazon Comprehend API calls (toxicity, prompt safety, PII) is crucial for minimizing latency, as all filters must run before the FM is invoked. It correctly maps the requirements to the specific Comprehend features: toxicity detection for offensive content, prompt safety classification for inappropriate advice, and PII detection with entity redaction to protect customer privacy. Configuring thresholds and alarms are standard best practices for operationalizing such a filtering system.

A. This option fails the privacy requirement because it specifies PII detection without redaction, which would identify but not protect the sensitive information.
B. Building a custom classification model is high effort and unnecessary when standard Comprehend features meet the needs. Applying PII detection conditionally is inefficient.
C. A multi-stage, serial process would increase latency, violating the requirement for acceptable response times, as each filter would have to wait for the previous one to complete.

1. AWS Documentation. (2024). Amazon Comprehend Developer Guide. See "Detecting personally identifiable information (PII)". (Describes the DetectPiiEntities operation and the ability to redact PII).

2. AWS Documentation. (2024). Amazon Comprehend Developer Guide. See "Prompt safety classification". (Explains this feature is designed to classify prompts to help prevent the generation of unsafe content).

3. AWS Machine Learning Blog. (2024, February 29). Implement content moderation in generative AI applications with Amazon Comprehend and Amazon Bedrock. (Provides an architecture that uses Comprehend for content moderation, including toxicity and PII detection, as a pre-processing step before calling the Bedrock FM).

4. AWS Documentation. (2024). Amazon Comprehend Developer Guide. See "Content moderation". (Details the toxicity detection feature, which classifies content into different toxicity categories).

The core issues are hallucination (recommending unavailable products) and high perceived latency. The most effective solution for grounding a model in factual, up-to-date information is Retrieval Augmented Generation (RAG). Creating an Amazon Bedrock knowledge base with the company's product catalog and implementing RAG ensures the model's responses are based only on available products, directly resolving the relevance and availability issues. While the PerformanceConfigLatency parameter is not a real API parameter, the intent of the option points towards optimizing the RAG process, which is the correct architectural pattern to solve the primary problem.

A. Guardrails are for enforcing safety policies, not for grounding responses in a product catalog. Provisioned throughput addresses consistent load, not initial generation latency or hallucination.
B. Prompt engineering alone is often insufficient to prevent hallucinations with large, dynamic datasets like a product catalog. Streaming reduces perceived latency but does not fix the grounding problem.
D. Post-generation validation adds latency and complexity. Caching is ineffective because most interactions are unique, as stated in the problem description.

1. AWS Documentation. (2024). Knowledge bases for Amazon Bedrock. AWS. Retrieved from https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html. (This explains how knowledge bases provide models with access to data sources for RAG, which is used to "deliver more relevant and accurate responses").

2. AWS Documentation. (2024). Retrieval Augmented Generation (RAG). AWS. Retrieved from https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-foundation-models-rag.html. (This page describes RAG as a technique to reduce hallucination by providing external, verifiable knowledge to the model).

3. Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems, 33, 9459-9474. (This foundational academic paper establishes RAG as a method for models to use external knowledge, improving factual accuracy).

This solution comprehensively addresses all requirements using purpose-built AWS services. Amazon Bedrock's model invocation logging feature can be configured to send detailed logs, including prompts and responses, to Amazon CloudWatch Logs. These logs can then be archived to Amazon S3 to meet the 2-year retention requirement. Amazon Bedrock Prompt Management is designed for creating, managing, and versioning prompts. Using parameterized prompts allows for consistent terminology while variables adapt to local patient demographics. The versioning feature, combined with an organizational process, directly supports the need for an approval workflow before deploying prompt changes, ensuring governance and control.

A. AWS CloudTrail logs API management events (e.g., CreatePrompt), not the actual content of prompts and responses, failing the comprehensive logging requirement.
C. Using AWS Lambda for prompt generation and SQS for an approval workflow is overly complex and less manageable than the dedicated Bedrock Prompt Management service.
D. This approach uses services inappropriately. S3 Object Lock is for WORM compliance, not for managing prompt versions, and Bedrock Prompt Management is the superior, purpose-built tool.

1. Model Invocation Logging: The Amazon Bedrock User Guide explains how to log model invocations, including prompts and responses, to either Amazon CloudWatch Logs or Amazon S3. This directly supports the logging, auditing, and retention requirements.

Source: AWS Documentation, Amazon Bedrock User Guide, section "Monitor Amazon Bedrock," subsection "Log model invocations."

2. Prompt Management and Versioning: The Amazon Bedrock User Guide details the use of prompt libraries for managing and reusing prompts. It describes creating placeholders (variables) for dynamic content and managing different versions of a prompt, which is essential for the approval workflow and adapting to demographics.

Source: AWS Documentation, Amazon Bedrock User Guide, section "Prompts," subsection "Manage prompts in a library."

3. Long-term Log Retention: The Amazon CloudWatch Logs User Guide describes the process of exporting log data to Amazon S3. This is a standard pattern for cost-effective, long-term retention and archival, fulfilling the 2-year requirement.

Source: AWS Documentation, Amazon CloudWatch Logs User Guide, section "Working with log groups and log streams," subsection "Export log data to Amazon S3."

AWS Glue Data Catalog tracks tables, columns, and source objects, automatically recording end-to-end lineage that can be queried. Amazon Bedrock Guardrails provide real-time PII detection and block/mask actions on prompts and completions. AWS CloudTrail records every Bedrock API call, delivering immutable audit logs to Amazon S3. Amazon Macie continuously classifies and reports sensitive data in S3. Publishing Macie findings to CloudWatch and visualising them in dashboards supplies automated compliance evidence—satisfying lineage, real-time PII control, and audit-trail requirements.

B AWS Config tracks resource configuration, not data lineage; WAF rules cannot inspect Bedrock traffic. C DataSync copies data but does not provide lineage; Session Manager logs user shells, not Bedrock calls. D Athena only queries; CloudWatch custom metrics can’t guarantee PII filtering; Rekognition detects images, not textual PII.

1. AWS Glue Data Catalog Guide – “Lineage data”

2024-03-12

§“Understanding lineage graphs”.

2. Amazon Bedrock Developer Guide – “Using Guardrails for PII detection”

Rev. 2024-03-25.

3. AWS CloudTrail User Guide – “Logging Amazon Bedrock API calls”

2024-02-14

§“Data events”.

4. Amazon Macie User Guide – “Automated sensitive data discovery” & “Publishing findings to CloudWatch”

2024-03-01.

This solution correctly addresses all the requirements. Deploying each model to a separate Amazon SageMaker Serverless Inference endpoint allows for independent scaling and resource configuration tailored to each model's specific needs. SageMaker Serverless Inference is ideal for workloads with intermittent traffic, as it automatically scales compute resources up and down, even to zero, which optimizes costs during low-demand periods. To meet the strict low-latency (<500 ms) and high-concurrency (500 requests) requirements during predictable peak periods, configuring provisioned concurrency pre-warms the necessary resources, eliminating cold-start latency and ensuring consistent, fast performance.

A. A multi-model endpoint is not ideal for this low-latency scenario, as it can introduce latency when loading models from S3 into memory on demand, potentially violating the 500 ms response time requirement.
C. Amazon Bedrock is used for foundation models (FMs). The scenario describes custom-developed specialized models, which are typically deployed on Amazon SageMaker, not Bedrock.
D. Asynchronous inference is designed for long-running jobs with large payloads, not for real-time, low-latency (<500 ms) requests. It queues requests for background processing, which fundamentally conflicts with the application's response time requirement.

1. AWS SageMaker Developer Guide, "Provisioned Concurrency for Serverless Inference": This document explains how provisioned concurrency is used for serverless endpoints to handle predictable traffic patterns requiring low latency. It states, "When you configure provisioned concurrency for your endpoint, SageMaker launches and pre-warms a specified number of compute resources so that they are ready to respond to inference requests immediately," which directly addresses the peak load and latency requirements.

2. AWS SageMaker Developer Guide, "When to use Serverless Inference": This section highlights that Serverless Inference is ideal for "workloads with intermittent or infrequent traffic patterns" and that it "scales down to zero when there is no traffic, helping you to minimize your costs." This supports the cost-optimization requirement.

3. AWS SageMaker Developer Guide, "Amazon SageMaker Asynchronous Inference": This guide clarifies the use case for asynchronous inference: "This option is ideal for requests with large payload sizes... and long processing times...". This confirms it is unsuitable for the sub-500 ms latency requirement.

4. AWS SageMaker Developer Guide, "Deploy multiple models in one container behind one endpoint": This page on multi-model endpoints notes that "SageMaker loads models from S3 when they are first invoked and caches them in memory." This initial loading step can introduce latency, making it a risk for strict real-time performance guarantees.

This solution represents a well-configured and balanced guardrail policy. Setting content filters to "medium" effectively blocks harmful content while minimizing false positives. Defining "denied topics" with specific phrases is the correct method to prevent discussions on investment advice. The configuration uses multiple handling strategies by masking PII in responses while blocking sensitive financial information in user inputs, which meets a key requirement. Enabling evaluation for both inputs and outputs ensures comprehensive protection. This nuanced approach correctly uses the features of Amazon Bedrock Guardrails to enforce all specified policies effectively.

A. Setting all filters to "high" and blocking all PII is too aggressive, leading to high false positives and a poor user experience.
B. Amazon Bedrock does not support applying or chaining multiple guardrails to a single inference call; a single, comprehensive guardrail should be used.
D. This architecture is invalid. Chaining guardrails with Step Functions is not a supported pattern and would be highly inefficient and complex.

1. Amazon Bedrock User Guide

"Guardrails for Amazon Bedrock". This documentation details the configuration of all policies mentioned in option C.

2. Amazon Bedrock User Guide

"Configure policies in a guardrail". This section shows how to set up Content filters (with levels like MEDIUM)

Denied topics

and Sensitive information filters.

3. Amazon Bedrock User Guide

"Sensitive information filter". This page explicitly describes the different actions available

such as BLOCK and MASK ("Anonymize PII entities by replacing them with a placeholder")

confirming that multiple handling strategies are a native feature.

The problem requires querying highly interconnected data with multi-hop relationships, which is the primary strength of a graph database. Amazon Neptune Analytics is a graph analytics database engine optimized for this purpose. GraphRAG is a technique specifically designed to traverse these relationships to find relevant context for a RAG application. Using this with Amazon Bedrock Knowledge Bases provides a managed, low-overhead solution that directly addresses the need to analyze complex, indirect relationships comprehensively and quickly, meeting the sub-3-second response requirement.

B. Vector stores are not inherently optimized for multi-hop relationship traversal; implementing this with sequential Lambda queries adds complexity, latency, and operational overhead.
C. This option requires manual relationship mapping and self-managed EC2 instances, which creates significant operational overhead, contradicting a key requirement.
D. DynamoDB is not a graph database and is ill-suited for efficiently querying complex, multi-hop relationships without significant custom logic and performance trade-offs.

1. AWS News Blog (2024)

"New Amazon Bedrock Knowledge Bases with GraphRAG and Amazon Neptune Analytics for enhanced RAG". This official announcement describes the solution for "uncovering multi-hop relationships across various data sources to deliver more comprehensive and well-rounded responses."

2. AWS Documentation

Amazon Neptune

"What Is Amazon Neptune?". The documentation states

"Neptune is a purpose-built

high-performance graph database engine... It is optimized for storing billions of relationships and querying the graph with milliseconds latency."

The most robust and systematic solution is to treat prompt engineering as a software development lifecycle process. Implementing version control (e.g., Git) provides a historical record. A dedicated test suite with complex clinical documents ensures the system is evaluated against the problematic cases, not just simple ones. Using quantifiable metrics (e.g., ROUGE, BLEU, or domain-specific accuracy scores) and an automated framework allows for objective, repeatable comparison between prompt versions. This directly addresses the need to diagnose inconsistencies, compare performance against metrics, and maintain version history.

A. Manually testing with simple documents will not solve the problem, which occurs with complex documents. This approach lacks rigor and automated, quantifiable metrics.
C. A/B testing in production is for validating user experience, not for systematically diagnosing and fixing underlying prompt performance issues against established, objective metrics.
D. While a possible approach, it is overly complex for the core task. A standard MLOps/PromptOps framework (as in B) is a more direct and standard way to manage, test, and version prompts.

1. AWS Machine Learning Blog. (2023, November 17). Prompt engineering for foundation models on Amazon Bedrock. AWS. Retrieved from https://aws.amazon.com/blogs/machine-learning/prompt-engineering-for-foundation-models-on-amazon-bedrock/ (Discusses the iterative nature of prompt engineering, implying a need for testing and versioning).

2. Cobbe, K., et al. (2021). Training Verifiers to Solve Math Word Problems. arXiv:2110.14168 [cs.LG]. https://doi.org/10.48550/arXiv.2110.14168 (Section 4, "Results," demonstrates the use of test sets and metrics to evaluate model/prompt performance, a standard academic practice).

3. Stanford University. (n.d.). CS224N: NLP with Deep Learning | Winter 2021. Lecture 15. Retrieved from https://web.stanford.edu/class/cs224n/ (Courseware often covers model evaluation, emphasizing the need for robust test sets and metrics to ensure performance).

This scenario requires a solution that efficiently handles two distinct routing paths: a low-latency path for simple decisions and an orchestrated path for complex ones. A hybrid approach is optimal. Simple routing based on file extensions can be handled directly in the application code for minimal latency. For complex semantic analysis and routing, AWS Step Functions is the ideal service. It provides a visual workflow to orchestrate multiple steps, maintains a detailed execution history for auditing, and has built-in error handling (e.g., Catch fields) to implement fallback logic when a primary model fails. This separation of concerns meets all requirements effectively.

A. A single Lambda function for all logic would introduce unnecessary latency for simple requests and makes implementing robust, stateful fallbacks and history tracking more complex than using a dedicated orchestration service.
C. Using separate Step Functions workflows coordinated by EventBridge is overly complex. A single state machine can handle conditional logic and fallbacks internally, reducing architectural complexity and potential points of failure.
D. Amazon SQS is a queuing service, not an orchestration engine. While it decouples components, it does not provide the state management, detailed history, or built-in error handling needed for the complex routing workflow.

1. AWS Step Functions Developer Guide. (2024). What is AWS Step Functions? "AWS Step Functions is a visual workflow service that helps developers use AWS services to build distributed applications, automate processes, orchestrate microservices, and create data and machine learning (ML) pipelines."

2. AWS Step Functions Developer Guide. (2024). Error handling in Step Functions. "Step Functions state machines can be configured to handle errors... A state can have a field named Catch, whose value must be an array of objects that are known as catchers."

3. AWS Step Functions Developer Guide. (2024). Execution history. "Step Functions provides visibility into each execution's history. You can review the detailed information... in the Step Functions console."