AWS Generative AI Developer - Professional (AIP-C01) — Questions d'entraînement et examen blanc

Amazon Q Developer (l'option « Amazon Q Developer ») est la bonne réponse. Amazon Q Developer est l'assistant de codage propulsé par l'IA d'AWS, qui fournit des suggestions de code en ligne, de la génération de code, une aide au refactoring et de l'analyse de sécurité directement dans les IDE les plus courants. C'est le successeur d'AWS CodeWhisperer, renommé et intégré à Amazon Q Developer. Pourquoi chaque option incorrecte est fausse : - A. AWS Cloud9 — AWS Cloud9 est un environnement de développement intégré (IDE) dans le cloud qui permet d'écrire, d'exécuter et de déboguer du code avec un simple navigateur. C'est bien un IDE, mais il ne fournit pas lui-même de suggestions de code en ligne par IA, de génération de code ni d'aide au refactoring. C'est l'environnement, pas l'assistant IA. - C. AWS CodeWhisperer (legacy) — CodeWhisperer fournissait bien des suggestions de code par IA, mais il a été renommé et ses capacités ont été intégrées à Amazon Q Developer. En tant que marque héritée et abandonnée, ce n'est pas la bonne réponse actuelle. AWS oriente désormais les utilisateurs vers Amazon Q Developer pour ces fonctionnalités. - D. Amazon CodeGuru Reviewer — Amazon CodeGuru Reviewer est un service de revue de code automatisée qui utilise le machine learning pour détecter des problèmes dans le code Java et Python. D'après la documentation AWS, il « fournit des recommandations d'amélioration pour le code Java et Python » via des revues de code, mais il ne propose pas de suggestions de code en ligne en temps réel, de génération de code ni d'aide au refactoring au sein d'un IDE. De plus, depuis le 7 novembre 2025, il n'est plus possible de créer de nouvelles associations de dépôts. (Source : https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)

Amazon SageMaker AI est la bonne réponse, car ce service prend nativement en charge les Model Cards comme fonctionnalité de documentation des modèles de ML. Les SageMaker Model Cards permettent aux développeurs de créer, modifier et partager par programmation la documentation de leurs modèles, y compris les cas d'usage prévus, les limites, les résultats d'évaluation et les détails métier.

Comme le confirme la documentation AWS CloudFormation, le type de ressource `AWS::SageMaker::ModelCard` existe et inclut des propriétés comme `BusinessDetails` pour documenter « des informations sur la façon dont le modèle contribue aux objectifs métier ». Cela montre que les SageMaker Model Cards sont une fonctionnalité à part entière de SageMaker AI, qui peut être créée et gérée par programmation via le SDK SageMaker, l'API ou des outils d'infrastructure as code comme CloudFormation.

Pourquoi chaque option incorrecte est fausse :

• A) AWS CloudFormation — CloudFormation peut certes *provisionner* des SageMaker Model Cards (via `AWS::SageMaker::ModelCard`), mais CloudFormation est lui-même un service d'infrastructure as code, pas le service qui *prend en charge* la création de model cards en tant que fonctionnalité. Les model cards appartiennent à SageMaker AI ; CloudFormation ne fait qu'orchestrer leur déploiement.

• B) Amazon Bedrock — Amazon Bedrock est un service managé qui donne accès à des modèles de fondation via une API. Il ne propose pas de fonctionnalité de model card pour documenter les limites d'un modèle, ses cas d'usage prévus ou ses résultats d'évaluation. D'après le guide de décision AWS, Bedrock se concentre sur l'accès aux FM sans gestion d'infrastructure, tandis que SageMaker fournit l'outillage complet du cycle de vie ML, y compris les fonctionnalités de gouvernance comme les model cards.

• D) Amazon Q Business — Amazon Q Business est un assistant propulsé par l'IA destiné aux entreprises, qui aide les collaborateurs à obtenir des réponses à partir des données de l'entreprise. Il n'offre pas de fonctionnalité de model card pour documenter les métadonnées et les informations de gouvernance des modèles de ML.

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

Provisioned Throughput avec des model units (l'option « Provisioned Throughput avec des model units ») est la bonne réponse. Quand une application de production exige une capacité d'invocation de modèle garantie et dédiée pour un trafic constant et à fort volume, Provisioned Throughput est le choix approprié. D'après la documentation AWS, Provisioned Throughput permet d'acheter de la capacité dédiée mesurée en model units, avec des durées d'engagement (1 mois ou 6 mois), ce qui garantit à ton application un débit réservé sans subir le throttling des pools de capacité partagée. Comme l'indique la documentation : « Amazon Bedrock propose des options de capacité flexibles pour s'adapter aux besoins de ta charge de travail et à ton budget. Comprendre les différences entre les tiers on-demand (Flex, Priority, Standard), le tier réservé, le traitement batch et l'inférence cross-region t'aide à optimiser à la fois les performances et les coûts. » Provisioned Throughput relève de la catégorie du tier réservé, qui fournit une capacité garantie. Pourquoi chaque option incorrecte est fausse : - A. Tier On-Demand Standard — Les tiers On-Demand (dont Standard) offrent un accès à l'usage, mais ne garantissent pas de capacité dédiée. Ils subissent du throttling en période de forte demande, puisque la capacité est partagée entre les clients. Cela ne répond pas à l'exigence d'une capacité « garantie ». - B. Inférence batch — L'inférence batch est conçue pour traiter de gros volumes de requêtes de façon asynchrone (pas en temps réel). Elle est optimisée pour réduire les coûts sur des charges de travail massives qui n'exigent pas de réponse immédiate, ce qui la rend inadaptée à une application de production servant du trafic en direct. - C. Cross-Region Inference avec profil Global — Cross-Region Inference répartit les requêtes entre plusieurs régions AWS pour améliorer la disponibilité et réduire la latence, mais elle ne fournit pas de capacité dédiée garantie. Elle repose toujours sur les pools de capacité on-demand des différentes régions et constitue avant tout une stratégie de résilience et d'optimisation de la latence, pas un mécanisme de réservation de capacité. (Source : https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html et https://docs.aws.amazon.com/bedrock/latest/userguide/capacity-limits-cost-optimization.html)

La bonne réponse est Des workflows utilisateurs synthétiques avec une validation de sortie spécifique à l'IA pour les taux d'hallucination et la dérive sémantique. Pour valider des modèles d'IA générative après une mise à jour, les développeurs ont besoin d'approches de validation automatisées et reproductibles qui mesurent spécifiquement des métriques propres à l'IA, comme les taux d'hallucination et la dérive sémantique. Les workflows utilisateurs synthétiques appuyés sur des golden datasets (sorties attendues connues) permettent de détecter systématiquement les régressions de qualité du modèle avant de l'exposer au trafic en direct. Cette approche rejoint les capacités de configuration des données de validation d'Amazon Bedrock, où des jeux de validation servent, pendant la personnalisation du modèle, à évaluer ses performances face à des benchmarks connus. Amazon Bedrock prend en charge la configuration des données de validation (validationDataConfig) dans le cadre des jobs de personnalisation de modèle, ce qui permet d'évaluer la qualité du modèle à l'aide de jeux de validation structurés. Ce principe s'étend à la validation post-déploiement, où les workflows synthétiques jouent le rôle de tests de régression pour les métriques de qualité propres à l'IA. Pourquoi les autres options sont fausses : - B (Des tests de charge avec Apache JMeter) : Les tests de charge mesurent des caractéristiques de performance comme le débit, la latence et la gestion de la concurrence. Ils n'évaluent pas la qualité sémantique, les taux d'hallucination ni la dérive de contenu, qui sont précisément les préoccupations évoquées dans la question. - C (Des tests manuels réalisés par les membres de l'équipe) : Les tests manuels ne passent pas à l'échelle, ne sont pas reproductibles et restent très subjectifs. Ils ne peuvent pas mesurer systématiquement les taux d'hallucination ni détecter une dérive sémantique subtile entre les mises à jour du modèle. Ils introduisent aussi des délais importants dans la pipeline de déploiement. - D (Des tests A/B avec de vrais utilisateurs immédiatement après le déploiement) : Les tests A/B avec de vrais utilisateurs exposent des personnes réelles à un modèle potentiellement dégradé avant la fin de la validation. Les bonnes pratiques imposent que les contrôles de qualité propres à l'IA (détection d'hallucinations, analyse de la dérive sémantique) aient lieu *avant* de servir du trafic en direct, et non après. Cette approche fait courir le risque de mauvaises expériences utilisateur et de préjudices liés à des sorties hallucinées. (Source : https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)