AWS Builder Center
Notas de alguien que ya pasó el AWS Certified Generative AI Developer – Professional

Notas de alguien que ya pasó el AWS Certified Generative AI Developer – Professional

Notas de alguien que ya pasó el AWS Certified Generative AI Developer – Professional

Solutions Architect
Si estás preparando el AWS Certified Generative AI Developer – Professional, probablemente ya notaste algo:
el temario es grande y no siempre es claro qué estudiar a fondo y qué solo entender por encima 🤔
Después de presentar y aprobar el examen, me quedó una sensación muy clara, y por eso escribo estas notas:
👉 aproximadamente el 70% de las preguntas tenían que ver, directa o indirectamente, con RAG.
No siempre decía “RAG” explícitamente, pero el patrón se repetía una y otra vez:
recuperación de contexto, embeddings, chunking, guardrails y calidad de las respuestas.
Este post no es una guía oficial. Es una colección de apuntes reales, de builder a builder, sobre en qué valió la pena invertir tiempo y qué cosas, honestamente, no pesaron tanto como esperaba.

🧠 Amazon Bedrock: el punto de entrada a casi todo

Amazon Bedrock fue el servicio más presente durante el examen.
No tanto por preguntas aisladas del servicio, sino porque muchas arquitecturas RAG parten desde Bedrock.
En lo que yo me enfoqué:
  • Elegir el modelo correcto según el caso (chat, resumen, Q&A)
  • Diferencias prácticas entre invocar un modelo y usar Agents
  • Uso de Knowledge Bases como implementación administrada de RAG
  • Guardrails (este tema apareció bastante)
  • Costos a nivel conceptual (decisiones, no números)
Si solo puedes dominar un servicio, que sea Bedrock, pero siempre pensándolo dentro de un flujo RAG.

🔐 Guardrails: más importantes de lo que parecen

Algo que sí vi repetirse fue el uso de Guardrails dentro de Bedrock.
No te van a pedir configurarlos paso a paso, pero sí esperan que sepas:
  • Qué problema resuelven
  • Cuándo usarlos (PII, contenido sensible, compliance)
  • Por qué son clave en soluciones empresariales
En varias preguntas, Guardrails aparecía como la pieza que hacía viable la solución en producción, no como un extra.

🧩 Una nota rápida sobre Amazon Bedrock AgentCore

Amazon Bedrock AgentCore
En mi caso, solo me apareció una pregunta relacionada con AgentCore.
No es un tema central, pero sí vale la pena saber qué es y cuándo aparece:
  • Orquestación de agentes más compleja
  • Flujos con múltiples pasos y decisiones
Mi recomendación: entenderlo a nivel conceptual y seguir adelante.

🚀 RAG: el verdadero corazón del examen

Si tuviera que resumir el examen en una frase sería esta:
si entiendes bien RAG, ya llevas gran parte del camino recorrido.
RAG aparece en:
  • Chatbots empresariales
  • Q&A sobre información interna
  • Asistentes internos
  • Sistemas que necesitan contexto confiable
Aquí no basta con saber “qué es RAG”. El examen evalúa qué tan bien lo diseñas.

🗂️ Amazon S3 dentro de RAG

Amazon S3 aparece como parte natural de muchas arquitecturas RAG.
No necesitas profundizar en features avanzados, pero sí entender cómo encaja dentro del flujo completo junto con embeddings y recuperación de contexto.

🔎 OpenSearch y búsqueda vectorial

Amazon OpenSearch Service aparece cuando el problema ya no es solo generar texto, sino recuperar la información correcta.
Aquí el examen espera que tengas claro:
  • Cuándo usar búsqueda semántica
  • Qué papel juegan los embeddings
  • Por qué traer buen contexto importa más que cambiar de modelo
Muchas preguntas no se resolvían cambiando el modelo, sino mejorando cómo se recupera la información.

🧩 Chunking: mucho más importante de lo que parece

Algo que sí me apareció varias veces, directa o indirectamente, fue el tema de estrategias de chunking.
No te van a pedir tamaños exactos ni fórmulas, pero sí esperan que entiendas las consecuencias.
Lo que yo me aseguré de entender bien:
  • Por qué el chunking es clave en RAG
  • Chunks grandes vs pequeños
  • Uso de overlap
  • Impacto del chunking en:
    • Calidad de la respuesta
    • Relevancia del contexto
    • Latencia
En varias preguntas, el problema no era el modelo ni el servicio, sino cómo se estaba dividiendo la información antes de generar embeddings.
Mi regla mental fue:
si el modelo no entiende bien el contexto, probablemente el problema está en el chunking.

⚙️ SageMaker: cuando RAG no es suficiente

Amazon SageMaker aparece cuando el escenario requiere más control, pero en mi experiencia mucho menos que RAG.
Lo vi sobre todo cuando el caso mencionaba:
  • Datasets propios
  • Fine-tuning
  • Pipelines o MLOps
Clave entender cuándo sí y cuándo no hace sentido usarlo.

🧷 Lambda + API Gateway: el glue del flujo

AWS Lambda y Amazon API Gateway aparecen como parte del flujo, no como el foco.
Generalmente:
API → Lambda → Bedrock → recuperación de contexto
El examen evalúa más el diseño completo del flujo que configuraciones específicas.

👀 CloudWatch: pensar en producción

Amazon CloudWatch apareció en varios escenarios donde la solución ya estaba en producción.
No se entra en configuraciones profundas, pero sí se espera que pienses en observabilidad.
Lo que yo me aseguré de entender:
  • Logs de Lambda y flujos que llaman a Bedrock
  • Métricas para detectar errores o comportamientos anómalos
  • Alarmas como parte de una solución enterprise-ready
Mi takeaway fue claro:
si la solución está en producción, CloudWatch casi siempre tiene que estar presente.

✍️ Prompt engineering y uso responsable

Algo importante: no todo se resuelve entrenando modelos.
El examen evalúa si sabes:
  • Mejorar respuestas con prompting
  • Reducir alucinaciones
  • Diseñar soluciones responsables
En varias preguntas, la mejor respuesta era ajustar el prompt o el flujo, no cambiar de servicio.

💡 Algunos tips prácticos que sí marcaron la diferencia (para mí)

📘 Skill Builder fue clave en este examen

Normalmente recomiendo Udemy, pero para esta certificación en particular,
Skill Builder fue 100% el camino.
No tanto por la teoría, sino porque:
  • Usa el mismo lenguaje del examen
  • Plantea escenarios muy similares
  • Te entrena para pensar como AWS espera que razones

📅 Programa tu examen

Hasta que no le pones fecha, el estudio se vuelve eterno.

⏱️ Reserva tiempo real en tu agenda

Este examen no se pasa estudiando “cuando se puede”.
Bloquear tiempo real en la agenda , aunque sea poco.

🔁 Si tuviera que estudiar otra vez

Este sería mi orden de enfoque:
  1. RAG (S3 + OpenSearch + embeddings + chunking + guardrails)
  2. Amazon Bedrock
  3. SageMaker (solo lo necesario)
  4. Lambda + API Gateway
  5. Observabilidad en producción (CloudWatch)

❓❓ ¿Qué estudié en Skill Builder? Seguí la guía oficial de 4 pasos de skill builder: ---> https://skillbuilder.aws/category/exam-prep/generative-ai-developer-professional-aip-c01 
Este examen no se trata de memorizar servicios, sino de entender cómo fluye la información y cómo darle buen contexto a un modelo, como lo haríamos en proyectos reales.
Si estás preparándote, ojalá estas notas te ayuden a estudiar con más claridad y menos ruido.
Y si eres mujer en tech y estás dudando si dar el paso, que esto sea otro recordatorio de que sí se puede 💪
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article