AWS Generative AI Developer - Professional (AIP-C01) — Preguntas de práctica y simulacro de examen

Amazon Q Developer (la opción “Amazon Q Developer”) es la respuesta correcta. Amazon Q Developer es el asistente de programación con IA de AWS, que ofrece sugerencias de código en línea, generación de código, ayuda con la refactorización y análisis de seguridad directamente dentro de los IDE más populares. Es el sucesor de AWS CodeWhisperer, que cambió de nombre y se integró en Amazon Q Developer. Por qué cada opción incorrecta está mal: - A. AWS Cloud9 — AWS Cloud9 es un entorno de desarrollo integrado (IDE) en la nube que te permite escribir, ejecutar y depurar código con solo un navegador. Aunque es un IDE, por sí mismo no ofrece sugerencias de código en línea con IA, generación de código ni ayuda con la refactorización. Es el entorno, no el asistente de IA. - C. AWS CodeWhisperer (legacy) — Si bien CodeWhisperer sí ofrecía sugerencias de código con IA, cambió de nombre y sus capacidades se integraron en Amazon Q Developer. Al ser una marca heredada y descontinuada, no es la respuesta correcta actual. Hoy AWS dirige a los usuarios a Amazon Q Developer para estas funciones. - D. Amazon CodeGuru Reviewer — Amazon CodeGuru Reviewer es un servicio de revisión automatizada de código que usa machine learning para detectar problemas en código Java y Python. Según la documentación de AWS, “ofrece recomendaciones para mejorar tu código Java y Python” mediante revisiones de código, pero no ofrece sugerencias de código en línea en tiempo real, generación de código ni ayuda con la refactorización dentro de un IDE. Además, desde el 7 de noviembre de 2025 ya no se pueden crear nuevas asociaciones de repositorios. (Fuente: https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)

Amazon SageMaker AI es la respuesta correcta porque admite de forma nativa las Model Cards como función para documentar modelos de ML. Las SageMaker Model Cards permiten a los desarrolladores crear, editar y compartir programáticamente la documentación de sus modelos, incluyendo casos de uso previstos, limitaciones, resultados de evaluación y detalles de negocio.

Como confirma la documentación de AWS CloudFormation, existe el tipo de recurso `AWS::SageMaker::ModelCard`, que incluye propiedades como `BusinessDetails` para documentar “información sobre cómo el modelo respalda los objetivos de negocio”. Esto demuestra que las SageMaker Model Cards son una función de primera clase de SageMaker AI, que se puede crear y administrar programáticamente mediante el SDK de SageMaker, la API o herramientas de infraestructura como código, como CloudFormation.

Por qué cada opción incorrecta está mal:

• A) AWS CloudFormation — Aunque CloudFormation puede *aprovisionar* SageMaker Model Cards (mediante `AWS::SageMaker::ModelCard`), CloudFormation en sí es un servicio de infraestructura como código, no el servicio que *admite* la creación de model cards como función. La funcionalidad de model cards pertenece a SageMaker AI; CloudFormation solo orquesta su despliegue.

• B) Amazon Bedrock — Amazon Bedrock es un servicio administrado para acceder a modelos fundacionales mediante una API. No ofrece una función de model cards para documentar limitaciones del modelo, casos de uso previstos ni resultados de evaluación. Según la guía de decisión de AWS, Bedrock se centra en hacer accesibles los FM sin administrar infraestructura, mientras que SageMaker aporta el conjunto de herramientas para todo el ciclo de vida de ML, incluidas funciones de gobernanza como las model cards.

• D) Amazon Q Business — Amazon Q Business es un asistente con IA para uso empresarial que ayuda a los empleados a obtener respuestas a partir de los datos de la compañía. No ofrece funcionalidad de model cards para documentar metadatos ni información de gobernanza de modelos de ML.

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

Provisioned Throughput con model units (la opción “Provisioned Throughput con model units”) es la respuesta correcta. Cuando una aplicación de producción requiere capacidad de invocación de modelos garantizada y dedicada para tráfico constante y de alto volumen, Provisioned Throughput es la opción adecuada. Según la documentación de AWS, Provisioned Throughput te permite comprar capacidad dedicada medida en model units, con plazos de compromiso (1 mes o 6 meses), de modo que tu aplicación tenga rendimiento reservado sin quedar sujeta al throttling de los pools de capacidad compartida. Como indica la documentación: “Amazon Bedrock ofrece opciones de capacidad flexibles para ajustarse a los requisitos de tu carga de trabajo y a tu presupuesto. Entender las diferencias entre los niveles on-demand (Flex, Priority, Standard), el nivel reservado, el procesamiento batch y la inferencia entre regiones te ayuda a optimizar tanto el rendimiento como el costo.” Provisioned Throughput pertenece a la categoría de nivel reservado, que proporciona capacidad garantizada. Por qué cada opción incorrecta está mal: - A. Nivel On-Demand Standard — Los niveles On-Demand (incluido Standard) ofrecen acceso de pago por uso, pero no garantizan capacidad dedicada. Están sujetos a throttling en periodos de alta demanda, ya que la capacidad se comparte entre clientes. Esto no cumple el requisito de capacidad “garantizada”. - B. Inferencia batch — La inferencia batch está diseñada para procesar grandes volúmenes de solicitudes de forma asíncrona (no en tiempo real). Está optimizada para ahorrar costos en cargas de trabajo masivas que no requieren respuestas inmediatas, lo que la hace inadecuada para una aplicación de producción que atiende tráfico en vivo. - C. Cross-Region Inference con perfil Global — Cross-Region Inference distribuye las solicitudes entre varias regiones de AWS para mejorar la disponibilidad y reducir la latencia, pero no proporciona capacidad dedicada garantizada. Sigue dependiendo de los pools de capacidad on-demand de las distintas regiones y es sobre todo una estrategia de resiliencia y optimización de latencia, no un mecanismo de reserva de capacidad. (Fuente: https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html y https://docs.aws.amazon.com/bedrock/latest/userguide/capacity-limits-cost-optimization.html)

La respuesta correcta es Flujos de usuario sintéticos con validación de salida específica para IA que mida tasas de alucinación y deriva semántica. Al validar modelos de IA generativa después de una actualización, los desarrolladores necesitan enfoques de validación automatizados y repetibles que midan específicamente métricas relevantes para la IA, como las tasas de alucinación y la deriva semántica. Los flujos de usuario sintéticos con golden datasets (salidas esperadas conocidas) permiten detectar de forma sistemática regresiones en la calidad del modelo antes de exponerlo al tráfico en vivo. Este enfoque se alinea con las capacidades de configuración de datos de validación de Amazon Bedrock, donde los conjuntos de validación se usan durante la personalización del modelo para evaluar su desempeño frente a benchmarks conocidos. Amazon Bedrock admite la configuración de datos de validación (validationDataConfig) como parte de los trabajos de personalización de modelos, lo que permite evaluar la calidad del modelo con conjuntos de validación estructurados. Este principio se extiende a la validación posterior al despliegue, donde los flujos sintéticos funcionan como pruebas de regresión para métricas de calidad específicas de la IA. Por qué las otras opciones están mal: - B (Pruebas de carga con Apache JMeter): Las pruebas de carga miden características de rendimiento como throughput, latencia y manejo de concurrencia. No evalúan la calidad semántica, las tasas de alucinación ni la deriva de contenido, que son justamente las preocupaciones planteadas en la pregunta. - C (Pruebas manuales realizadas por miembros del equipo): Las pruebas manuales no escalan, no son repetibles y son muy subjetivas. No pueden medir de forma sistemática las tasas de alucinación ni detectar derivas semánticas sutiles entre actualizaciones del modelo. Además, introducen retrasos importantes en el pipeline de despliegue. - D (Pruebas A/B con usuarios reales inmediatamente después del despliegue): Las pruebas A/B con usuarios reales exponen a personas reales a un modelo potencialmente degradado antes de completar la validación. Las buenas prácticas indican que las comprobaciones de calidad específicas de la IA (detección de alucinaciones, análisis de deriva semántica) deben ocurrir *antes* de servir tráfico en vivo, no después. Este enfoque arriesga malas experiencias de usuario y posibles daños derivados de salidas alucinadas. (Fuente: https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)