AWS Generative AI Developer - Professional (AIP-C01) — Übungsfragen und Probeprüfung

Amazon Q Developer (die Option „Amazon Q Developer“) ist die richtige Antwort. Amazon Q Developer ist der KI-gestützte Coding-Assistent von AWS, der Inline-Codevorschläge, Codegenerierung, Refactoring-Unterstützung und Security-Scanning direkt in gängigen IDEs bietet. Er ist der Nachfolger von AWS CodeWhisperer, das umbenannt und in Amazon Q Developer integriert wurde. Warum jede falsche Option falsch ist: - A. AWS Cloud9 — AWS Cloud9 ist eine cloudbasierte integrierte Entwicklungsumgebung (IDE), in der du Code allein mit einem Browser schreiben, ausführen und debuggen kannst. Es ist zwar eine IDE, liefert selbst aber keine KI-gestützten Inline-Codevorschläge, keine Codegenerierung und keine Refactoring-Unterstützung. Es ist die Umgebung, nicht der KI-Assistent. - C. AWS CodeWhisperer (legacy) — CodeWhisperer lieferte zwar KI-gestützte Codevorschläge, wurde aber umbenannt, und seine Funktionen sind in Amazon Q Developer aufgegangen. Als veraltete Bezeichnung ist es nicht die aktuell richtige Antwort. AWS verweist Nutzer für diese Funktionen inzwischen auf Amazon Q Developer. - D. Amazon CodeGuru Reviewer — Amazon CodeGuru Reviewer ist ein Service für automatisierte Code-Reviews, der mit Machine Learning Probleme in Java- und Python-Code erkennt. Laut AWS-Dokumentation „liefert er Empfehlungen zur Verbesserung deines Java- und Python-Codes“ über Code-Reviews, bietet aber keine Inline-Codevorschläge in Echtzeit, keine Codegenerierung und keine Refactoring-Unterstützung innerhalb einer IDE. Außerdem können seit dem 7. November 2025 keine neuen Repository-Verknüpfungen mehr angelegt werden. (Quelle: https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)

Amazon SageMaker AI ist die richtige Antwort, weil der Service Model Cards nativ als Funktion zum Dokumentieren von ML-Modellen unterstützt. Mit SageMaker Model Cards können Entwickler Dokumentation zu ihren Modellen programmatisch erstellen, bearbeiten und teilen – inklusive vorgesehener Anwendungsfälle, Einschränkungen, Evaluierungsergebnisse und geschäftlicher Details.

Wie die AWS CloudFormation-Dokumentation bestätigt, existiert der Ressourcentyp `AWS::SageMaker::ModelCard`, der Eigenschaften wie `BusinessDetails` enthält, um „Informationen darüber, wie das Modell Geschäftsziele unterstützt“ zu dokumentieren. Das zeigt, dass SageMaker Model Cards eine vollwertige Funktion von SageMaker AI sind, die sich über das SageMaker SDK, die API oder Infrastructure-as-Code-Werkzeuge wie CloudFormation programmatisch erstellen und verwalten lässt.

Warum jede falsche Option falsch ist:

• A) AWS CloudFormation — CloudFormation kann SageMaker Model Cards zwar *bereitstellen* (über `AWS::SageMaker::ModelCard`), ist aber selbst ein Infrastructure-as-Code-Service und nicht der Service, der das Erstellen von Model Cards als Funktion *unterstützt*. Die Model-Card-Funktionalität gehört zu SageMaker AI; CloudFormation orchestriert lediglich deren Bereitstellung.

• B) Amazon Bedrock — Amazon Bedrock ist ein Managed Service für den Zugriff auf Foundation Models über eine API. Er bietet keine Model-Card-Funktion zum Dokumentieren von Modelleinschränkungen, vorgesehenen Anwendungsfällen oder Evaluierungsergebnissen. Laut dem AWS-Entscheidungsleitfaden konzentriert sich Bedrock darauf, FMs ohne Infrastrukturverwaltung zugänglich zu machen, während SageMaker das Tooling für den gesamten ML-Lebenszyklus bereitstellt, inklusive Governance-Funktionen wie Model Cards.

• D) Amazon Q Business — Amazon Q Business ist ein KI-gestützter Assistent für den Unternehmenseinsatz, der Mitarbeitenden hilft, Antworten aus Unternehmensdaten zu bekommen. Er bietet keine Model-Card-Funktionalität zum Dokumentieren von Metadaten und Governance-Informationen zu ML-Modellen.

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

Provisioned Throughput mit Model Units (die Option „Provisioned Throughput mit Model Units“) ist die richtige Antwort. Wenn eine produktive Anwendung garantierte, dedizierte Kapazität für Modellaufrufe bei konstant hohem Traffic braucht, ist Provisioned Throughput die passende Wahl. Laut AWS-Dokumentation kannst du mit Provisioned Throughput dedizierte Kapazität kaufen, die in Model Units gemessen wird, mit Laufzeiten von 1 Monat oder 6 Monaten, sodass deiner Anwendung reservierter Durchsatz sicher ist und sie nicht dem Throttling geteilter Kapazitätspools unterliegt. In der Dokumentation heißt es: „Amazon Bedrock bietet flexible Kapazitätsoptionen, die zu deinen Workload-Anforderungen und deinem Budget passen. Wenn du die Unterschiede zwischen den On-Demand-Tiers (Flex, Priority, Standard), dem Reserved Tier, der Batch-Verarbeitung und Cross-Region Inference verstehst, kannst du sowohl Performance als auch Kosten optimieren.“ Provisioned Throughput gehört zur Kategorie Reserved Tier, die garantierte Kapazität bietet. Warum jede falsche Option falsch ist: - A. On-Demand Standard Tier — On-Demand-Tiers (auch Standard) bieten nutzungsbasierten Zugriff, garantieren aber keine dedizierte Kapazität. In Phasen hoher Nachfrage unterliegen sie dem Throttling, weil die Kapazität von mehreren Kunden geteilt wird. Damit ist die Anforderung nach „garantierter“ Kapazität nicht erfüllt. - B. Batch-Inferenz — Batch-Inferenz ist dafür gedacht, große Mengen an Anfragen asynchron (also nicht in Echtzeit) zu verarbeiten. Sie ist auf Kostenersparnis bei Massen-Workloads optimiert, die keine sofortigen Antworten brauchen, und damit für eine produktive Anwendung mit Live-Traffic ungeeignet. - C. Cross-Region Inference mit Global-Profil — Cross-Region Inference verteilt Anfragen über mehrere AWS-Regionen, um die Verfügbarkeit zu erhöhen und die Latenz zu senken, liefert aber keine garantierte dedizierte Kapazität. Sie greift weiterhin auf On-Demand-Kapazitätspools in verschiedenen Regionen zurück und ist in erster Linie eine Strategie für Resilienz und Latenzoptimierung, kein Mechanismus zur Kapazitätsreservierung. (Quelle: https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html und https://docs.aws.amazon.com/bedrock/latest/userguide/capacity-limits-cost-optimization.html)

Die richtige Antwort ist Synthetische Nutzer-Workflows mit KI-spezifischer Ausgabevalidierung für Halluzinationsraten und semantischen Drift. Wenn du generative KI-Modelle nach Updates validierst, brauchst du automatisierte, wiederholbare Validierungsansätze, die gezielt KI-relevante Kennzahlen wie Halluzinationsraten und semantischen Drift messen. Synthetische Nutzer-Workflows mit Golden Datasets (bekannten erwarteten Ausgaben) erlauben es Entwicklern, Qualitätsregressionen des Modells systematisch zu erkennen, bevor das Modell Live-Traffic sieht. Dieser Ansatz passt zu den Möglichkeiten der Validierungsdaten-Konfiguration von Amazon Bedrock, bei der Validierungsdatensätze während der Modellanpassung genutzt werden, um die Modellleistung an bekannten Benchmarks zu bewerten. Amazon Bedrock unterstützt die Validierungsdaten-Konfiguration (validationDataConfig) als Teil von Model-Customization-Jobs, womit sich die Modellqualität mit strukturierten Validierungsdatensätzen beurteilen lässt. Dieses Prinzip lässt sich auf die Validierung nach dem Deployment übertragen, wo synthetische Workflows als Regressionstests für KI-spezifische Qualitätskennzahlen dienen. Warum die anderen Optionen falsch sind: - B (Lasttests mit Apache JMeter): Lasttests messen Performance-Eigenschaften wie Durchsatz, Latenz und den Umgang mit Nebenläufigkeit. Sie bewerten weder semantische Qualität noch Halluzinationsraten oder inhaltlichen Drift — genau die Punkte also, um die es in der Frage geht. - C (Manuelle Tests durch Teammitglieder): Manuelle Tests skalieren nicht, sind nicht wiederholbar und stark subjektiv. Sie können Halluzinationsraten nicht systematisch messen und subtilen semantischen Drift über Modell-Updates hinweg nicht erkennen. Außerdem verzögern sie die Deployment-Pipeline erheblich. - D (A/B-Tests mit echten Nutzern direkt nach dem Deployment): A/B-Tests mit echten Nutzern setzen reale Nutzer einem möglicherweise verschlechterten Modell aus, bevor die Validierung abgeschlossen ist. Best Practices verlangen, dass KI-spezifische Qualitätsprüfungen (Halluzinationserkennung, Analyse des semantischen Drifts) *vor* dem Ausliefern von Live-Traffic stattfinden, nicht danach. Dieser Ansatz riskiert schlechte Nutzererlebnisse und mögliche Schäden durch halluzinierte Ausgaben. (Quelle: https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)