The AWS Certified Generative AI Developer - Professional (AIP-C01)

Option B best satisfies the requirements with the least custom development effort by using native Amazon Bedrock capabilities for prompt experimentation, traffic management, fairness monitoring, and alerting. Amazon Bedrock Prompt Management allows teams to define and manage multiple prompt variants without code changes, making it ideal for comparing recommendation strategies across demographic groups.

Amazon Bedrock Flows enables controlled traffic allocation between prompt variants, which supports real-time A/B testing. This allows the company to collect live fairness metrics under production conditions instead of relying on offline analysis. Because Flows are fully managed, they eliminate the need for custom routing or experimentation frameworks.

Amazon Bedrock guardrails provide built-in monitoring and intervention mechanisms. When configured for fairness-related checks, guardrails can detect policy violations and surface metrics such as InvocationsIntervened, which indicate when outputs are modified or blocked due to rule enforcement. These metrics integrate directly with Amazon CloudWatch, enabling real-time dashboards and threshold-based alarms. Setting an alarm at a 15% discrepancy threshold satisfies the alerting requirement with minimal configuration.

Weekly reporting can be generated from CloudWatch metrics using scheduled exports or dashboards without building custom analytics pipelines. Option A requires significant custom post-processing logic. Option C introduces an additional service with higher operational overhead and is not optimized for real-time monitoring. Option D focuses on offline evaluation jobs and does not provide continuous real-time fairness monitoring.

Therefore, Option B provides the most AWS-native, scalable, and low-effort solution for fairness evaluation and monitoring.

Option C is the correct solution because AWS AppConfig is designed for real-time, validated, centrally managed configuration changes with safe rollout, immediate propagation, and rollback support—exactly matching the company’s requirements.

By storing routing rules, cost thresholds, regulatory constraints, and A/B testing logic in AWS AppConfig, the company can switch between Amazon Bedrock foundation models without redeploying Lambda code. AppConfig supports feature flags, dynamic configuration updates, JSON schema validation, and staged rollouts, which are essential for safely managing complex and frequently changing routing logic.

Using the AWS AppConfig Agent, Lambda functions can retrieve cached configurations efficiently, ensuring low latency even under thousands of concurrent requests. This approach allows the Lambda function to apply proprietary business logic—such as user tier, transaction value, Region compliance, and real-time cost metrics—before selecting the appropriate FM.

Option A is operationally fragile because environment variable changes require function restarts and do not support validation or controlled rollouts. Option B is too limited for complex, dynamic logic and is difficult to maintain at scale. Option D misuses Lambda authorizers, which are intended for authentication and authorization, not high-frequency dynamic routing decisions.

Therefore, Option C provides the most scalable, flexible, and low-overhead architecture for dynamic, regulation-aware FM routing in a global GenAI system.

Option B best meets the combined resiliency and observability requirements because it applies AWS-recommended retry behavior for transient throttling and enables true distributed tracing across service boundaries. During peak traffic, intermittent failures are commonly caused by throttling and other transient conditions. The AWS SDK standard retry mode provides exponential backoff with jitter, which reduces synchronized retry storms, prevents cascading failures, and improves overall system stability. Jitter is important because it spreads retry attempts over time, reducing load amplification during throttling events.

For observability, AWS X-Ray provides distributed tracing that follows a request across components such as API Gateway or load balancers, application services, and downstream calls to Amazon Bedrock. X-Ray can identify where latency is being introduced and which downstream call is contributing most to end-to-end response time. This is required to “identify latency contributors” and isolate performance issues under load.

The requirement also states that the company must correlate performance issues with specific FM characteristics. X-Ray annotations are designed for this purpose: the application can annotate traces with the model ID, inference parameters, region, or inference profile used. This enables filtering and analysis (for example, comparing latency or error patterns by model, parameter set, or endpoint configuration) without building a separate telemetry system.

Option A’s fixed-delay retries increase synchronized retry behavior and do not provide distributed tracing. Option C does not prevent cascading failures and cannot provide cross-service tracing. Option D is incorrect because CloudTrail is an audit logging service and does not provide distributed tracing for request latency analysis.

Therefore, Option B provides the correct combination of resilient retries and deep, model-correlated distributed observability for Amazon Bedrock workloads.

Option B meets the requirement to combine scalable automated evaluation with targeted human oversight using managed AWS GenAI capabilities. Amazon Bedrock evaluations enable systematic, repeatable quality assessment across large volumes of interactions. Using an LLM-as-a-judge approach with a strong evaluator model such as Anthropic Claude Sonnet allows the company to automatically score outputs for dimensions like factual accuracy, conversational appropriateness, and policy alignment. This directly supports “automated quality evaluations at scale” without building custom scoring models.

However, financial recommendations add higher risk because regulatory compliance requires additional enforcement beyond general quality scoring. Amazon Bedrock guardrails provide a dedicated policy enforcement layer that can block or intervene when responses violate compliance constraints. Guardrails are particularly important for preventing disallowed financial guidance patterns and ensuring consistent behavior across deployments.

The requirement also calls for “targeted human reviews of critical interactions.” Amazon Augmented AI (A2I) is a managed human review service that supports routing specific items to human reviewers based on rules or confidence thresholds. In this design, the system can automatically send only high-risk or policy-flagged interactions to qualified financial experts for review, keeping human effort focused where it matters most while maintaining scale.

Option A is not scalable because it requires manual review of all responses. Option C relies on static rules and end-user feedback, which is insufficient for regulatory compliance and factual accuracy assurance. Option D provides monitoring but not structured quality evaluation or policy enforcement.

Therefore, Option B provides the most complete, AWS-aligned solution for scalable evaluation plus human oversight in a regulated financial context.

Option C is the correct solution because it uses Amazon Bedrock cross-Region inference profiles, which are explicitly designed to support regional data residency, private connectivity, and resilience with minimal operational overhead.

By using a Europe-scoped inference profile, the application ensures that all inference requests are routed only within European Regions where the FM is deployed, such as eu-central-1 and eu-west-3. This satisfies data residency requirements while still providing resilience and load distribution across Regions.

Configuring an Amazon Bedrock VPC endpoint ensures that all traffic remains on the AWS private network. No public endpoints are used, which aligns with the company’s private networking requirements.

Extending existing SCPs to allow inference profile usage ensures that employees can access the FM only in approved Regions, maintaining governance across the Control Tower environment.

Options A and B introduce unnecessary custom routing layers and EC2 management. Option D moves away from Amazon Bedrock entirely and increases operational complexity.

Therefore, Option C is the only solution that satisfies private access, regional confinement, governance controls, and low operational overhead.

The correct combination is C and D because together they enforce centralized governance over both model access and prompt content controls , which are the two core requirements of the scenario.

To ensure employees can use only approved Amazon Bedrock models , governance must be enforced at the organization level and not rely on individual application logic. Service Control Policies (SCPs) are the strongest control mechanism available in AWS Organizations because they define the maximum permissions an account or principal can have. In option C , the SCP prevents any Amazon Bedrock model invocation unless a centrally approved guardrail identifier is specified. This ensures that guardrails are always enforced, regardless of how or where the invocation originates. The additional use of IAM permissions boundaries ensures that even within allowed accounts, employees are restricted to invoking only explicitly approved foundation models.

To prevent specific topics and proprietary information from being included in prompts , Amazon Bedrock Guardrails must be used. Guardrails operate inline during model invocation and can block disallowed content before it is processed by the model. Option D correctly specifies a block filtering policy , which is appropriate when content must be prevented entirely rather than partially redacted. Deploying the guardrail using AWS CloudFormation StackSets allows the company to centrally manage and consistently deploy the same guardrail configuration across all accounts in the organization, ensuring uniform enforcement.

Option E uses mask filtering, which is better suited for redacting sensitive output rather than preventing prohibited content from being submitted in prompts. Option B attempts to use SCPs alone but does not enforce guardrail deployment or content filtering. Option A incorrectly places guardrail enforcement in permissions boundaries, which are not designed to validate request parameters such as guardrail identifiers.

By combining SCP-based enforcement with centrally deployed Bedrock guardrails , options C and D together provide strong, scalable, and centrally managed controls for both content safety and model governance across the organization.

AWS Step Functions provides native support for human-in-the-loop workflows, making it the best fit for regulatory oversight requirements. The waitForTaskToken integration pattern is explicitly designed to pause a workflow until an external actor—such as a human reviewer—completes a task.

In this architecture, AI-generated recommendations are sent to a human technician for review. The workflow pauses execution using a task token. Once the technician approves or rejects the recommendation, an AWS Lambda function calls SendTaskSuccess or SendTaskFailure, allowing the workflow to continue deterministically.

This approach ensures full auditability, as Step Functions records every state transition, timestamp, and execution path. Storing review outcomes in Amazon DynamoDB provides durable, queryable audit records required for regulatory compliance.

Option A requires custom orchestration and lacks native workflow state management. Option C incorrectly uses AWS Glue, which is not designed for approval workflows. Option D uses caching instead of durable audit storage and introduces unnecessary complexity.

Therefore, Option B is the AWS-recommended, lowest-risk, and most auditable solution for mandatory human review of AI outputs.

Option A is the correct solution because it relies on native Amazon Bedrock capabilities to deliver transparency, auditability, scalability, and low latency with minimal operational overhead. Amazon Bedrock Knowledge Bases provide a fully managed Retrieval Augmented Generation (RAG) implementation that automatically handles document ingestion, embedding, retrieval, and source attribution, enabling the application to cite authoritative content without building custom pipelines.

Enabling tracing for Amazon Bedrock Agents provides end-to-end visibility into agent reasoning steps, tool usage, and model interactions. This satisfies the requirement for comprehensive audit trails and supports regulatory review in financial services environments. Structured prompts further ensure that responses explicitly present reasoning and supporting evidence in a controlled, auditable format.

Using Amazon API Gateway and AWS Lambda allows the application to scale automatically to thousands of concurrent users without capacity planning. These services are designed for bursty workloads and can easily support the stated requirement of up to 10,000 concurrent users. Amazon CloudFront reduces latency by caching and accelerating content delivery, helping the application meet the strict 2-second response-time requirement.

Option B introduces a custom RAG pipeline with OpenSearch, increasing operational complexity and maintenance effort. Option C lacks native RAG integration and does not provide transparent reasoning or citation management. Option D focuses on offline compliance reporting rather than real-time transparency and low-latency responses.

Therefore, Option A best meets all requirements while minimizing infrastructure and operational overhead.

Option B is correct because the application is currently invoking the base foundation model identifier, which routes traffic to the on-demand capacity pool rather than the company’s purchased provisioned throughput. In Amazon Bedrock, provisioned throughput is attached to a specific provisioned resource created through the provisioned throughput APIs. To consume that reserved capacity, inference requests must target the provisioned resource identifier that represents the purchased throughput, not the generic model identifier used for on-demand inference.

The code snippet uses modelId= " anthropic.claude-v2 " . This value selects the on-demand endpoint for that model. As a result, requests are subject to on-demand quotas and throttling behavior, while the provisioned throughput remains idle. This directly explains the CloudWatch observation: provisioned capacity metrics show unused capacity because no traffic is being directed to the provisioned resource, and the on-demand path is throttling because it is exceeding the applicable on-demand limits during peak volume.

Replacing the modelId value with the provisioned throughput ARN returned by the CreateProvisionedModelThroughput workflow ensures the runtime invocation is routed to the reserved capacity. Once traffic is directed correctly, the purchased model units provide the consistent throughput required for predictable performance during business hours, which is exactly why provisioned throughput is used.

Option A could increase capacity, but it does not fix the core issue that the application is not using the provisioned resource at all. Option C can reduce the impact of throttling temporarily, but it adds latency and does not guarantee consistent throughput; it also still wastes the provisioned capacity. Option D changes the response delivery mechanism, but throttling is a capacity routing and quota issue, not a streaming API issue.