AWS Generative AI Developer - Professional (AIP-C01) — Practice Questions and Mock Exam

Amazon Q Developer (the option “Amazon Q Developer”) is the correct answer. Amazon Q Developer is AWS's AI-powered coding assistant that provides inline code suggestions, code generation, refactoring assistance, and security scanning directly within popular IDEs. It is the successor to AWS CodeWhisperer, which has been rebranded and integrated into Amazon Q Developer. Why each incorrect option is wrong: - A. AWS Cloud9 — AWS Cloud9 is a cloud-based integrated development environment (IDE) that lets you write, run, and debug code with just a browser. While it is an IDE, it does not itself provide AI-powered inline code suggestions, code generation, or refactoring assistance. It is the environment, not the AI assistant. - C. AWS CodeWhisperer (legacy) — While CodeWhisperer did provide AI-powered code suggestions, it has been rebranded and its capabilities have been folded into Amazon Q Developer. As a legacy/deprecated branding, it is not the current correct answer. AWS now directs users to Amazon Q Developer for these features. - D. Amazon CodeGuru Reviewer — Amazon CodeGuru Reviewer is an automated code review service that uses machine learning to detect issues in Java and Python code. According to AWS documentation, it "provides recommendations for improvements to your Java and Python code" through code reviews, but it does not provide real-time inline code suggestions, code generation, or refactoring assistance within an IDE. Additionally, as of November 7, 2025, new repository associations can no longer be created. (Source: https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)

Amazon SageMaker AI is the correct answer because it natively supports Model Cards as a feature for documenting ML models. SageMaker Model Cards allow developers to programmatically create, edit, and share documentation about their models, including intended use cases, limitations, evaluation results, and business details.

As confirmed by the AWS CloudFormation documentation, the `AWS::SageMaker::ModelCard` resource type exists, which includes properties like `BusinessDetails` for documenting "information about how the model supports business goals." This demonstrates that SageMaker Model Cards are a first-class SageMaker AI feature that can be created and managed programmatically through the SageMaker SDK, API, or infrastructure-as-code tools like CloudFormation.

Why each incorrect option is wrong:

• A) AWS CloudFormation — While CloudFormation can *provision* SageMaker Model Cards (via `AWS::SageMaker::ModelCard`), CloudFormation itself is an infrastructure-as-code service, not the service that *supports* model card creation as a feature. The model card functionality belongs to SageMaker AI; CloudFormation merely orchestrates its deployment.

• B) Amazon Bedrock — Amazon Bedrock is a managed service for accessing foundation models via API. It does not provide a model card feature for documenting model limitations, intended use cases, or evaluation results. According to the AWS decision guide, Bedrock focuses on making FMs accessible without managing infrastructure, while SageMaker provides the full ML lifecycle tooling including governance features like model cards.

• D) Amazon Q Business — Amazon Q Business is an AI-powered assistant for enterprise use that helps employees get answers from company data. It does not offer model card functionality for documenting ML model metadata and governance information.

(Source: https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-sagemaker-modelcard-businessdetails.html)

Provisioned Throughput with model units (the option “Provisioned Throughput with model units”) is the correct answer. When a production application requires guaranteed, dedicated model invocation capacity for consistent, high-volume traffic, Provisioned Throughput is the appropriate choice. According to AWS documentation, Provisioned Throughput allows you to purchase dedicated capacity measured in model units, with commitment terms (1-month or 6-month), ensuring your application has reserved throughput without being subject to throttling from shared capacity pools. As stated in the documentation: "Amazon Bedrock offers flexible capacity options to match your workload requirements and budget. Understanding the differences between on-demand tiers (Flex, Priority, Standard), reserved tier, batch processing, and cross-region inference helps you optimize both performance and cost." Provisioned Throughput falls under the reserved tier category, which provides guaranteed capacity. Why each incorrect option is wrong: - A. On-Demand Standard tier — On-Demand tiers (including Standard) provide pay-per-use access but do not guarantee dedicated capacity. They are subject to throttling during periods of high demand since capacity is shared across customers. This does not meet the requirement for "guaranteed" capacity. - B. Batch inference — Batch inference is designed for processing large volumes of requests asynchronously (not in real-time). It is optimized for cost savings on bulk workloads that don't require immediate responses, making it unsuitable for a production application serving live traffic. - C. Cross-Region Inference with Global profile — Cross-Region Inference distributes requests across multiple AWS regions to improve availability and reduce latency, but it does not provide guaranteed dedicated capacity. It still relies on on-demand capacity pools in various regions and is primarily a resilience and latency optimization strategy, not a capacity reservation mechanism. (Source: https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html and https://docs.aws.amazon.com/bedrock/latest/userguide/capacity-limits-cost-optimization.html)

The correct answer is Synthetic user workflows with AI-specific output validation for hallucination rates and semantic drift. When validating generative AI models after updates, developers need automated, repeatable validation approaches that specifically measure AI-relevant metrics like hallucination rates and semantic drift. Synthetic user workflows with golden datasets (known expected outputs) allow developers to systematically detect regressions in model quality before exposing the model to live traffic. This approach aligns with Amazon Bedrock's validation data configuration capabilities, where validation datasets are used during model customization to evaluate model performance against known benchmarks. Amazon Bedrock supports validation data configuration (validationDataConfig) as part of model customization jobs, which enables developers to assess model quality using structured validation datasets. This principle extends to post-deployment validation where synthetic workflows serve as regression tests for AI-specific quality metrics. Why the other options are wrong: - B (Load testing with Apache JMeter): Load testing measures performance characteristics like throughput, latency, and concurrency handling. It does not evaluate semantic quality, hallucination rates, or content drift — which are the specific concerns stated in the question. - C (Manual testing by team members): Manual testing is not scalable, not repeatable, and highly subjective. It cannot systematically measure hallucination rates or detect subtle semantic drift across model updates. It also introduces significant delays in the deployment pipeline. - D (A/B testing with live users immediately after deployment): A/B testing with live users exposes real users to a potentially degraded model before validation is complete. Best practices dictate that AI-specific quality checks (hallucination detection, semantic drift analysis) should occur *before* serving live traffic, not after. This approach risks negative user experiences and potential harm from hallucinated outputs. (Source: https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)