Semana 11 · Módulo 11 de 11

Repaso final: simulacros, técnica de examen y visión transversal

La semana que convierte lo estudiado en aprobado: simulacros, técnica para un examen Professional de 180 minutos, un repaso de los 20 task statements, los pares de servicios que más se confunden y todo lo que necesitas para reservar, presentarte y dar el siguiente paso hacia el SAP-C03.

⏱ ~16 h de estudioTask statements: 1.11.21.31.41.51.62.12.22.32.42.53.13.23.33.44.14.24.35.15.2
Al terminar este módulo sabrás:
  • Hacer los simulacros 2 y 3 en condiciones reales y analizar cada fallo
  • Gestionar 75 preguntas largas en 180 minutos (210 con ESL) con lectura inversa, descarte y marcado
  • Repasar los 20 task statements con criterios de decisión rápidos
  • Distinguir los pares de servicios y técnicas que el examen usa como distractores
  • Diseñar soluciones completas de IA generativa y estimar su coste por tokens
  • Reservar el examen con ESL y llegar al día del examen sin sorpresas
Índice del módulo

Reparto de la semana

Esta semana no hay teoría nueva. Hay práctica en condiciones de examen, análisis de errores y repaso dirigido a tus dominios débiles. El simulacro 1 ya lo hiciste al final de la semana 10; su resultado decide en qué inviertes las horas de repaso.

Día Qué hacer Tiempo
Lunes Análisis del simulacro 1 (cuaderno de errores) y lectura de «Técnicas de examen» 2 h
Martes Repaso por task statement de los dos dominios con peor nota + sus tarjetas 2 h
Miércoles Simulacro 2 completo, cronometrado (180 o 210 min) 3,5 h
Jueves Análisis del simulacro 2 + «Pares que se confunden» 2 h
Viernes Lab 19: escenario 1 y 2 + Official Practice Question Set (gratis, 20 preguntas) 2 h
Sábado Simulacro 3 (o Official Practice Exam si tienes suscripción) + análisis 4,5 h
Domingo Lab 19, escenario 3; test y tarjetas de este módulo; repaso ligero del cuaderno de errores — (si te sobra tiempo)

Total: unas 16 horas. Si la semana se te queda corta, recorta el escenario 3 del lab, nunca un simulacro ni su análisis.

Por qué importa

El AIP-C01 es un examen Professional: 75 preguntas con escenarios largos, varias restricciones mezcladas (residencia de datos, coste, latencia, privacidad, IA responsable, esfuerzo operativo) y a menudo dos respuestas que parecen correctas. Saber qué hace cada servicio es necesario, pero no suficiente: el examen mide criterio. Esta semana entrenas tres cosas que no se aprenden leyendo teoría:

  1. Resistencia: tres horas (tres y media con ESL) de lectura en inglés sin perder concentración.
  2. Método: leer la pregunta final, subrayar requisitos duros, descartar, marcar y volver.
  3. Visión transversal: una misma pregunta mezcla RAG (dominio 1), Guardrails (dominio 3) y coste (dominio 4). Aquí repasas el temario cruzando dominios, como lo hace el examen.

Plan de la última semana

Los tres simulacros de la web

Simulacro Cuándo Para qué Objetivo
Simulacro 1 Final de la semana 10 Diagnóstico: descubrir tus dominios y task statements débiles La nota importa poco; importa el mapa de errores
Simulacro 2 Miércoles de la semana 11 Comprobar que el repaso dirigido funciona y entrenar el ritmo 75 % o más
Simulacro 3 Sábado de la semana 11 Ensayo general con las condiciones del día del examen 80 % o más

Cada simulacro tiene 75 preguntas repartidas por dominios como el examen real (≈ 31/26/20/12/11 %), con todos los task statements y entre 10 y 14 preguntas de respuesta múltiple.

Condiciones de ensayo: mismo horario que tendrás el día del examen, sin móvil, sin documentación, sin pausas (el examen online no permite levantarse), temporizador de 180 minutos (o 210 si vas a pedir ESL), y todas las preguntas contestadas antes de que acabe el tiempo.

Recursos oficiales de práctica (AWS Skill Builder)

El plan de preparación oficial tiene cuatro pasos. Todo está en inglés, que es justo lo que te conviene. Verificado el 01/10/2026:

Recurso Duración Acceso Cuándo usarlo
Official Practice Question Set (20 preguntas con explicación) 48 min Gratis Esta semana, antes del simulacro 2. Es la mejor muestra del estilo real
Exam Prep Overview y Domain 1-5 Review (vídeos, ~1 h por dominio) ~5 h Gratis Los dominios que te salgan débiles en el simulacro 1
Official Pretest (longitud de examen real) 3 h Suscripción Si tienes suscripción, como alternativa al simulacro 2
Domain 1-5 Practice y AWS SimuLearn (dominios 1 y 2) 5 × 1 h + 2 × 1 h Suscripción Para reforzar dominios concretos
Official Practice Exam 3 h Suscripción El mejor ensayo general: sustitúyelo por el simulacro 3 o hazlo además

El cuaderno de errores

Tras cada simulacro, apunta cada pregunta fallada y cada acierto dudoso en una tabla como esta:

Pregunta Task statement Qué elegí Qué era Por qué fallé Regla que me llevo
s2-17 1.5 Fine-tuning RAG con Knowledge Bases No vi «documentos que cambian a diario» Datos que cambian → RAG, nunca reentrenar
s2-42 4.1 Provisioned Throughput Batch inference Confundí «volumen alto» con «tráfico constante» Sin necesidad de respuesta inmediata → batch (≈ 50 % más barato)

Clasifica el motivo en una de estas cuatro categorías, porque cada una se arregla de forma distinta:

  • No sabía el concepto → vuelve al módulo y a su test.
  • Leí mal el enunciado (se me pasó un requisito o el calificador) → practica la lectura inversa.
  • Dudé entre dos y elegí mal → repasa el par en «Pares que se confunden».
  • Falta de tiempo → revisa tu ritmo con los puntos de control.

El día antes del examen, relee solo la columna «Regla que me llevo».

Si no llegas al 80 %

  • Entre 70 y 80 %: vas bien. Repasa los task statements con más fallos y repite sus tests en modo repaso. Mantén la fecha.
  • Por debajo del 70 % en el simulacro 3: plantéate reprogramar una o dos semanas (se puede hasta 24 horas antes de la cita, como máximo dos veces). Una semana extra de repaso dirigido suele valer más que 150 USD de un segundo intento.
  • Si fallas siempre el mismo dominio, vuelve a su lab: lo que se ha hecho con las manos se recuerda mucho mejor.

Técnicas de examen

1. Gestiona el tiempo: unos 2,4 minutos por pregunta

180 minutos para 75 preguntas son 2,4 minutos por pregunta. Con la adaptación ESL (210 minutos), 2,8 minutos. Parece mucho, pero los enunciados del AIP-C01 son largos: una pregunta de 150 palabras con cinco opciones largas se lleva fácilmente tres minutos si la lees de arriba abajo.

Puntos de control:

Momento Sin ESL (180 min) Con ESL (210 min)
Pregunta 25 minuto 55-60 minuto 65-70
Pregunta 50 minuto 115-120 minuto 135-140
Pregunta 75 (primera pasada terminada) minuto 150-160 minuto 175-185
Revisión de marcadas 20-30 min 25-35 min

Si vas por detrás en un punto de control, marca y avanza más rápido en las siguientes: una pregunta en la que te atascas cinco minutos vale lo mismo que una que resuelves en uno.

2. Lee primero la pregunta final

La última frase dice qué se pregunta y con qué criterio se decide. Léela antes que el escenario:

Which solution will meet these requirements with the LEAST operational overhead?

Con eso ya sabes que todas las opciones probablemente funcionan y que ganará la más gestionada. Después lee el escenario buscando dos cosas:

  • Requisitos duros (si no se cumplen, la opción queda descartada): «los datos no pueden salir de la UE», «sin reentrenar el modelo», «respuesta en menos de un segundo», «los usuarios solo ven los documentos a los que tienen acceso».
  • Ruido: contexto de negocio que no cambia la decisión («la empresa tiene 30 años de historia»).

3. Las palabras clave que deciden la respuesta

Palabra clave (inglés) Qué te pide Suele apuntar a
LEAST operational overhead / LEAST development effort La opción más gestionada Bedrock antes que SageMaker AI, Knowledge Bases gestionada antes que pipeline propio, AgentCore antes que agentes en EC2, Guardrails antes que filtros propios
MOST cost-effective La más barata que cumpla todo Modelo más pequeño, batch inference, prompt caching, caché semántica, S3 Vectors, Flex tier, cascada de modelos
without modifying application code / without redeploying Configuración externa AWS AppConfig, Prompt Management con versiones (sin aliases), perfiles de inferencia, alias de Flows o de Lambda
near real-time / as the response is generated Streaming ConverseStream / InvokeModelWithResponseStream, WebSockets o SSE
consistent latency, guaranteed throughput, custom model Capacidad reservada Provisioned Throughput (o Reserved tier)
not time-sensitive, overnight, large volume Asíncrono Batch inference, SQS
grounded, reduce hallucinations, cite sources Anclar en datos RAG, contextual grounding check, citas de Knowledge Bases
frequently changing data, up-to-date Conocimiento externo RAG con sincronización incremental, no fine-tuning
domain-specific style/terminology, consistent format Cambiar el comportamiento del modelo Fine-tuning (o few-shot si basta)
PII, mask, redact Privacidad Guardrails (sensitive information), Comprehend, Macie en S3
audit, traceability, who invoked Gobierno CloudTrail, model invocation logging, etiquetado de metadatos
data residency, must not leave the Region/EU Soberanía Modelo in-Region o perfil geográfico eu., nunca global
private connectivity, no internet Red VPC interface endpoint (PrivateLink) para Bedrock
human approval, review before Humano en el bucle Step Functions con callback (task token), API Gateway para feedback

4. Descarte sistemático

En casi todas las preguntas puedes eliminar dos opciones en menos de un minuto. Motivos típicos:

  • No cumple un requisito duro: usa un perfil de inferencia global cuando los datos deben quedarse en la UE; propone fine-tuning cuando «no se puede reentrenar».
  • Servicio real en el sitio equivocado: Macie para filtrar las respuestas del modelo (Macie analiza datos en S3, no respuestas en tiempo real); CloudTrail para ver el contenido de los prompts (CloudTrail registra llamadas a la API, el contenido está en los invocation logs).
  • Más trabajo del necesario: desplegar un modelo en EC2 con GPU cuando el enunciado pide lo mínimo operativo.
  • Coste desproporcionado: Provisioned Throughput para un piloto con tráfico esporádico.
  • Mezcla imposible: opciones que citan funciones inexistentes o combinaciones que no se soportan (por ejemplo, batch inference con tool calling, o Provisioned Throughput con un perfil de inferencia).

Entre las dos que quedan, relee el calificador de la última frase: suele decidir.

5. Marca para revisar y no dejes ninguna en blanco

  • Si en 3 minutos no lo tienes claro, responde tu mejor opción, marca con Flag for review y sigue. No hay penalización por fallar y las preguntas sin respuesta cuentan como incorrectas.
  • En la revisión final, cambia una respuesta solo si encuentras un motivo concreto (un requisito que no habías visto). Cambiar por intuición suele empeorar.
  • Las 10 preguntas sin puntuar no se identifican: no intentes adivinar cuáles son. Trata todas igual.

6. Respuesta múltiple

El enunciado dice cuántas elegir (Choose two / Choose three) y hay que acertar todas para puntuar. Método:

  1. Evalúa cada opción por separado como verdadera o falsa respecto al escenario.
  2. Si te salen más verdaderas de las pedidas, busca la que es «correcta pero no la mejor» (más cara, más operativa o que no resuelve el requisito principal).
  3. Desconfía de dos opciones que hacen lo mismo: normalmente las correctas son complementarias (por ejemplo, una controla la entrada y otra la salida; una cifra y otra audita).

7. Trucos específicos del AIP-C01

  • Bedrock primero: si nada en el enunciado exige control total del modelo, del hardware o de un modelo no disponible en Bedrock, la respuesta con Bedrock suele ganar a la de SageMaker AI o EC2.
  • La guía aún cita servicios cerrados a clientes nuevos (Agents Classic, Kendra, Q Business, A2I, Clarify, Ground Truth, Model Monitor). Pueden aparecer en opciones. Si una opción con uno de ellos cumple los requisitos, puede ser la correcta del examen; si hay una alternativa actual equivalente (AgentCore, Managed Knowledge Base), suele ser la preferida en preguntas nuevas. Detalle en «Servicios en mantenimiento» más abajo.
  • Nombres renombrados: el examen puede decir Prompt Flows (hoy Amazon Bedrock Flows) o AWS Chatbot (hoy Amazon Q Developer in chat applications). Son lo mismo.
  • Defensa en profundidad: cuando pregunta por seguridad o IA responsable, la respuesta buena suele combinar capas (entrada + modelo + salida + registro).
  • Cuidado con «entrenar»: el candidato objetivo no entrena modelos desde cero (fuera del alcance de la guía). Una opción que propone preentrenar un modelo propio casi nunca es la respuesta.

Repaso transversal por dominio

Con 65 preguntas puntuables, los pesos equivalen aproximadamente a 20, 17, 13, 8 y 7 preguntas por dominio.

Dominio Peso ≈ preguntas Task statements Servicios y conceptos estrella Qué mide en el fondo
1. Foundation Model Integration, Data Management, and Compliance 31 % 20 1.1-1.6 Bedrock (modelos, perfiles de inferencia), Knowledge Bases, S3 Vectors, OpenSearch, Aurora pgvector, chunking, embeddings, reranking, Prompt Management, Flows, Glue Data Quality, Textract, Transcribe, BDA, AppConfig Elegir modelo y arquitectura, preparar datos, diseñar RAG y gobernar prompts
2. Implementation and Integration 26 % 17 2.1-2.5 AgentCore, Strands Agents, MCP, Agent Squad, Step Functions, Provisioned Throughput, SageMaker AI endpoints, Converse API, streaming, API Gateway, EventBridge, SQS, Outposts, CodePipeline, Amplify, Kiro Construir y desplegar: agentes, APIs, integración empresarial, CI/CD
3. AI Safety, Security, and Governance 20 % 13 3.1-3.4 Guardrails, Comprehend, Macie, KMS, VPC endpoints, IAM, Lake Formation, CloudTrail, invocation logging, Glue Data Catalog, model cards, LLM-as-a-judge Proteger entrada, salida y datos; auditar; IA responsable
4. Operational Efficiency and Optimization 12 % 8 4.1-4.3 Prompt caching, caché semántica, batch inference, service tiers, cascada de modelos, CloudWatch, X-Ray, Cost Anomaly Detection, Managed Grafana Bajar coste y latencia, observar tokens y calidad
5. Testing, Validation, and Troubleshooting 11 % 7 5.1-5.2 Bedrock Evaluations (automática, humana, LLM como juez, RAG), AgentCore Evaluations, golden datasets, CloudWatch Logs Insights Medir calidad y diagnosticar fallos propios de la IA generativa

Repaso por task statement

Cada apartado resume lo esencial y una tabla «si el enunciado dice… piensa en…». Si una fila no te suena, vuelve al módulo enlazado.

1.1 Analizar requisitos y diseñar soluciones de IA generativa

Módulo: 01.

  • Diseño guiado por requisitos: modelo, patrón de integración (prompt directo, RAG, agente, flujo), despliegue (on-demand, provisionado, SageMaker AI).
  • Prueba de concepto antes de producción: Bedrock permite probar varios modelos sin infraestructura (playground, API, evaluaciones) y medir calidad, latencia y coste antes de invertir.
  • Componentes estandarizados: AWS Well-Architected Framework y la Generative AI Lens en la AWS Well-Architected Tool para revisar cargas de forma consistente.
Si el enunciado dice… Piensa en…
«validar viabilidad y valor de negocio antes de invertir» PoC en Bedrock con varios modelos y una evaluación comparativa
«revisar la arquitectura con las buenas prácticas de AWS para IA generativa» Well-Architected Tool con la Generative AI Lens
«plantillas reutilizables para que todos los equipos implementen igual» Componentes estándar en IaC (CDK/CloudFormation), Service Catalog, lente de Well-Architected
«respuestas basadas en documentos internos» RAG, no fine-tuning

1.2 Seleccionar y configurar modelos fundacionales

Módulo: 01 (y 06 para la personalización).

  • Criterios: calidad en tu tarea (benchmarks + evaluación propia), coste por token, latencia, ventana de contexto, modalidades, idiomas, licencia y disponibilidad regional.
  • Cambiar de modelo sin tocar código: el modelId en AWS AppConfig o en Prompt Management, leído por una Lambda detrás de API Gateway; la Converse API ayuda porque tiene el mismo formato para todos los modelos.
  • Resiliencia: perfiles de inferencia entre regiones (geográficos eu. si hay residencia de datos; globales si no), circuit breaker con Step Functions, degradación gradual (modelo alternativo, respuesta en caché, mensaje honesto).
  • Ciclo de vida de modelos personalizados: SageMaker AI (endpoints, Model Registry para versiones y aprobación), LoRA y adapters, pipelines automáticos, rollback, retirada de modelos (los modelos de Bedrock tienen fecha de fin de vida: planifica la migración).
Si el enunciado dice… Piensa en…
«cambiar de proveedor de modelo sin modificar el código» AppConfig (o Prompt Management) + Converse API
«el modelo no está disponible en la región de la aplicación» Cross-Region inference (perfil geográfico si hay residencia)
«seguir funcionando si el modelo principal falla» Circuit breaker en Step Functions + modelo de respaldo + degradación gradual
«versionar, aprobar y desplegar modelos ajustados con rollback» SageMaker Model Registry + pipeline CI/CD
«adaptar un modelo grande con poco coste de entrenamiento» PEFT: LoRA, adapters

1.3 Pipelines de validación y procesamiento de datos

Módulo: 02.

  • Validación: AWS Glue Data Quality (reglas), SageMaker Data Wrangler, Lambda personalizadas, métricas en CloudWatch.
  • Datos complejos: texto, imagen, audio (Amazon Transcribe), documentos (Amazon Textract, Bedrock Data Automation con blueprints), modelos multimodales de Bedrock, SageMaker Processing para trabajos pesados.
  • Formato de entrada: JSON del cuerpo de cada modelo en InvokeModel, lista de mensajes con roles en Converse, formato conversacional para diálogos.
  • Mejorar la calidad de la entrada: normalizar con Lambda, extraer entidades con Comprehend, reformular con un modelo de Bedrock.
Si el enunciado dice… Piensa en…
«reglas de calidad sobre datos en el Data Catalog antes de indexar» AWS Glue Data Quality
«transcribir llamadas y resumirlas» Transcribe → Bedrock
«extraer campos estructurados de facturas, imágenes, audio y vídeo con lo mínimo operativo» Bedrock Data Automation
«texto de formularios escaneados y tablas» Textract (o BDA)
«entidades para enriquecer el prompt» Comprehend

1.4 Diseñar e implementar almacenes vectoriales

Módulo: 02.

  • Opciones: S3 Vectors (el más barato, subsegundo, sin servidores), OpenSearch Service/Serverless (búsqueda híbrida, sharding, plugin neural, mucha escala), Aurora/RDS PostgreSQL con pgvector (si ya tienes SQL y quieres unir vectores con datos relacionales), Neptune Analytics (GraphRAG), DocumentDB, ElastiCache, DynamoDB para metadatos (con búsqueda vectorial nativa desde agosto de 2026, fuera de Knowledge Bases).
  • Metadatos: fecha (S3 object metadata), autor, dominio, permisos. Sirven para filtrar antes o durante la búsqueda.
  • Rendimiento a escala: sharding en OpenSearch, un índice por dominio, índices jerárquicos.
  • Integración con fuentes: conectores de la Managed Knowledge Base (S3, SharePoint, Confluence, Google Drive, OneDrive, web crawler, Custom; en una KB del cliente, solo S3 y Custom para fuentes nuevas desde el 30/09/2026), AppFlow, DataSync, Transfer Family.
  • Mantenimiento: sincronización incremental, detección de cambios con eventos de S3/EventBridge, refrescos programados.
Si el enunciado dice… Piensa en…
«millones de vectores, consultas poco frecuentes, coste mínimo» S3 Vectors
«combinar búsqueda por palabras clave y semántica, alta escala» OpenSearch (búsqueda híbrida)
«ya usamos PostgreSQL, unir embeddings con tablas de negocio» Aurora PostgreSQL + pgvector
«relaciones entre entidades, preguntas multi-salto» GraphRAG con Neptune Analytics
«filtrar por departamento, fecha o autor» Metadatos + filtrado en la recuperación
«el índice debe reflejar cambios de los documentos en minutos» Ingesta incremental disparada por eventos (S3 → EventBridge → sincronización)

1.5 Mecanismos de recuperación (RAG)

Módulo: 03.

  • Chunking: fijo, jerárquico (padre-hijo), semántico, sin fragmentar, o personalizado con Lambda.
  • Embeddings: Titan Text Embeddings V2 (256, 512 o 1.024 dimensiones), Cohere Embed, Nova Multimodal Embeddings (no disponible en la UE); más dimensiones = más precisión y más coste de almacenamiento.
  • Búsqueda: semántica, por palabras clave, híbrida; reranking con modelos de Bedrock (Amazon Rerank, Cohere Rerank).
  • Consultas: reformulación y expansión con un modelo, descomposición en subpreguntas (Lambda, Step Functions, query decomposition de Knowledge Bases).
  • Acceso estándar: tool/function calling para que el modelo consulte el índice, clientes MCP, APIs Retrieve y RetrieveAndGenerate.
Si el enunciado dice… Piensa en…
«los fragmentos cortan tablas o secciones a la mitad» Chunking jerárquico o semántico
«los resultados relevantes no aparecen entre los primeros» Reranker
«códigos de producto exactos que la búsqueda semántica no encuentra» Búsqueda híbrida
«preguntas compuestas que tocan varios documentos» Descomposición de consultas / agentic retrieval
«el agente debe consultar la base de conocimiento como herramienta» Function calling o servidor MCP delante de Retrieve

1.6 Ingeniería y gobierno de prompts

Módulo: 04.

  • Marcos de instrucciones: roles en el system prompt, plantillas con variables en Prompt Management, Guardrails para las reglas de IA responsable.
  • Contexto conversacional: historial en DynamoDB, Step Functions para pedir aclaraciones, Comprehend o el propio modelo para reconocer la intención.
  • Gobierno: versiones y variantes en Prompt Management, repositorio en S3, flujo de aprobación, CloudTrail para quién cambió qué, CloudWatch Logs para el acceso.
  • Calidad: pruebas de regresión de prompts (Lambda que valida la salida, Step Functions para casos límite, métricas en CloudWatch).
  • Técnicas: few-shot, chain-of-thought, salida con formato (JSON Schema), bucles de feedback.
  • Prompts complejos: Bedrock Flows (Prompt Flows) con cadenas, condiciones, nodos de KB y Lambda.
Si el enunciado dice… Piensa en…
«plantillas parametrizadas, versionadas y aprobadas» Prompt Management
«cadena de prompts con condiciones, sin código» Bedrock Flows
«detectar que un cambio de prompt empeora las respuestas» Suite de regresión con golden dataset + métricas en CloudWatch
«salida siempre en JSON válido» Instrucciones de formato + JSON Schema/structured output + validación posterior
«recordar la conversación entre sesiones» Historial en DynamoDB (o AgentCore Memory en agentes)

2.1 IA agéntica e integración de herramientas

Módulo: 05.

  • Agentes: un modelo que decide en bucle qué herramienta usar (patrón ReAct). En AWS: AgentCore (Runtime, Memory, Gateway, Identity, Observability, Policy, Evaluations, Code Interpreter, Browser), Strands Agents (SDK), MCP para herramientas, Agent Squad para multiagente.
  • Razonamiento estructurado: Step Functions para implementar ReAct o chain-of-thought con pasos explícitos.
  • Salvaguardas: condiciones de parada y máximo de iteraciones (Step Functions), timeouts (Lambda), límites de permisos con IAM, circuit breakers, AgentCore Policy sobre las llamadas a herramientas.
  • Coordinación: modelos especializados por tarea, ensembles con agregación, marcos de selección de modelo.
  • Humano en el bucle: Step Functions con aprobación (callback), API Gateway para recoger feedback.
  • Herramientas fiables: definiciones estándar (JSON Schema), validación de parámetros y manejo de errores en Lambda. Servidores MCP: en Lambda para herramientas ligeras sin estado; en ECS (o AgentCore Runtime) para herramientas complejas o con estado.
Si el enunciado dice… Piensa en…
«ejecutar un agente de cualquier framework, serverless, con aislamiento por sesión» AgentCore Runtime
«convertir APIs existentes y Lambdas en herramientas para agentes» AgentCore Gateway (MCP)
«el agente no debe hacer reembolsos de más de X sin aprobación» AgentCore Policy / IAM + aprobación humana con Step Functions
«evitar bucles infinitos del agente» Máximo de iteraciones, condición de parada, timeout
«varios agentes especializados que colaboran» Multiagente con Strands o Agent Squad sobre AgentCore Runtime

2.2 Estrategias de despliegue de modelos

Módulo: 06.

  • On-demand (pagas por token) para tráfico variable; Provisioned Throughput (Model Units por hora) para capacidad garantizada o modelos personalizados; SageMaker AI endpoints para modelos propios o no disponibles en Bedrock; Custom Model Import para traer pesos abiertos a Bedrock.
  • Retos propios de los LLM: memoria de GPU, carga de modelos grandes, capacidad de tokens por segundo; contenedores optimizados (ECS/EKS con GPU, contenedores de inferencia de LLM en SageMaker AI).
  • Optimización: modelos más pequeños para tareas concretas, cascada (un modelo barato resuelve lo rutinario y escala al grande solo cuando hace falta).
Si el enunciado dice… Piensa en…
«tráfico impredecible, pago por uso» On-demand (Standard; Flex si tolera más latencia)
«modelo ajustado con fine-tuning en Bedrock» Provisioned Throughput (o despliegue on-demand si el modelo lo admite)
«modelo open source con pesos propios en Bedrock, sin gestionar infraestructura» Custom Model Import
«control total del contenedor, GPU y framework de inferencia» SageMaker AI endpoints (o ECS/EKS con GPU)
«la mayoría de preguntas son simples; pocas son complejas» Cascada de modelos / Intelligent Prompt Routing

2.3 Arquitecturas de integración empresarial

Módulo: 06.

  • Conectividad: APIs hacia sistemas heredados, arquitecturas por eventos (EventBridge, SQS, SNS) para desacoplar, sincronización de datos.
  • Añadir IA a aplicaciones existentes: API Gateway como fachada de microservicios, Lambda para webhooks, EventBridge para reaccionar a eventos.
  • Acceso seguro: federación de identidades (IAM Identity Center, Cognito), RBAC para modelos y datos, mínimo privilegio en bedrock:InvokeModel por modelo.
  • Varias jurisdicciones: AWS Outposts para datos que deben quedarse en las instalaciones, AWS Wavelength en el edge 5G, rutas seguras entre nube y local.
  • CI/CD y gateway de IA generativa: CodePipeline y CodeBuild con pruebas automáticas y escaneos de seguridad, rollback; una capa de abstracción centralizada (gateway) que aplica autenticación, cuotas, registro y elección de modelo para toda la empresa.
Si el enunciado dice… Piensa en…
«desacoplar el CRM del procesamiento con IA» EventBridge / SQS + Lambda
«los datos de pacientes no pueden salir del hospital» Outposts (procesamiento local)
«todas las unidades de negocio consumen modelos con control central de cuotas y registro» Gateway de IA generativa (API Gateway + Lambda + registros)
«los empleados acceden con su identidad corporativa» IAM Identity Center / Cognito federado
«desplegar prompts y componentes con pruebas y vuelta atrás» CodePipeline + CodeBuild con quality gates

2.4 Integraciones con las APIs de los modelos

Módulo: 04.

  • Síncrono: InvokeModel o Converse desde Lambda, ECS o EC2. Asíncrono: SQS + consumidores con el SDK; batch inference para volumen.
  • Tiempo real: ConverseStream o InvokeModelWithResponseStream; al cliente, por WebSockets (API Gateway WebSocket API) o server-sent events.
  • Resiliencia: backoff exponencial con jitter (el SDK lo trae), rate limiting en API Gateway, fallback a otro modelo, X-Ray para trazar.
  • Enrutado: estático en código, dinámico por contenido con Step Functions, por métricas, o con transformaciones en API Gateway.
Si el enunciado dice… Piensa en…
«misma integración para varios modelos» Converse API
«mostrar la respuesta mientras se genera» ConverseStream + WebSocket/SSE
«ThrottlingException en picos» Backoff exponencial con jitter + cola SQS + revisar cuotas / perfil de inferencia
«validar las peticiones antes de llegar al backend» API Gateway request validation
«enviar consultas de código a un modelo y de legal a otro» Enrutado por contenido (Step Functions o clasificador)

2.5 Patrones de integración de aplicaciones y herramientas de desarrollo

Módulo: 06.

  • APIs para IA generativa: streaming por API Gateway, control de límites de tokens, reintentos ante timeouts.
  • Interfaces accesibles: AWS Amplify (componentes de UI), especificaciones OpenAPI (API-first), Flows como constructor sin código.
  • Mejoras de negocio: Lambda para enriquecer un CRM, Step Functions para procesar documentos, Bedrock Data Automation.
  • Productividad: la guía cita Amazon Q Developer; sus plugins de IDE están en retirada (altas bloqueadas desde mayo de 2026, fin de soporte el 30/04/2027) y la alternativa es Kiro.
  • Aplicaciones avanzadas: Strands Agents y Agent Squad, Step Functions para patrones de agentes, cadenas de prompts en Bedrock.
  • Troubleshooting: CloudWatch Logs Insights sobre prompts y respuestas, X-Ray para trazas.
Si el enunciado dice… Piensa en…
«pipeline de documentos: extraer, clasificar, resumir, guardar» Step Functions + BDA/Textract + Bedrock
«frontend web con autenticación y componentes de chat rápidos» Amplify + Cognito
«buscar en los registros los prompts que causan errores» CloudWatch Logs Insights sobre invocation logs
«asistente de código para el equipo» Kiro (Q Developer en la guía)

3.1 Controles de seguridad de entrada y salida

Módulo: 07.

  • Guardrails en entrada y salida: content filters (incluido Prompt Attack), denied topics, word filters, sensitive information, contextual grounding y Automated Reasoning checks. ApplyGuardrail permite usarlos con cualquier modelo, incluso fuera de Bedrock.
  • Salidas deterministas: text-to-SQL en vez de que el modelo invente cifras; JSON Schema para forzar estructura.
  • Alucinaciones: anclar con Knowledge Bases, puntuaciones de confianza, verificación por similitud semántica.
  • Defensa en profundidad: preprocesado (Comprehend), guardrail del modelo, validación posterior (Lambda), filtrado en API Gateway.
  • Amenazas: prompt injection y jailbreak (filtro Prompt Attack, separar instrucciones de datos, etiquetar la entrada del usuario), pruebas adversarias automatizadas.
Si el enunciado dice… Piensa en…
«usuarios intentan que el modelo ignore sus instrucciones» Guardrails content filter Prompt Attack + etiquetado de entrada
«que el chatbot no hable de inversiones» Denied topics
«la respuesta debe estar respaldada por los documentos recuperados» Contextual grounding check
«verificar que la respuesta cumple unas reglas de negocio de forma lógica y explicable» Automated Reasoning checks
«el mismo filtro para un modelo en SageMaker AI» ApplyGuardrail

3.2 Seguridad y privacidad de los datos

Módulo: 07.

  • Entornos protegidos: VPC interface endpoints (PrivateLink) para Bedrock, políticas de IAM (y de endpoint), Lake Formation para acceso granular a datos, CloudWatch para vigilar el acceso.
  • Privacidad: Comprehend y Macie para detectar PII (Macie en S3), funciones nativas de Bedrock (no usa tus prompts para entrenar modelos ni los comparte con los proveedores), Guardrails para enmascarar en la salida, S3 Lifecycle para retención.
  • Técnicas: enmascarado, anonimización, cifrado con KMS (y Encryption SDK en cliente), secretos en Secrets Manager.
Si el enunciado dice… Piensa en…
«el tráfico a Bedrock no puede pasar por internet» VPC interface endpoint + política de endpoint
«descubrir PII en los documentos de S3 antes de indexarlos» Macie
«enmascarar PII en la respuesta del chatbot» Guardrails sensitive information (mask)
«redactar PII del texto antes de enviarlo al modelo» Comprehend (DetectPiiEntities) o Guardrails en la entrada
«borrar las conversaciones a los 30 días» S3 Lifecycle / TTL de DynamoDB
«permisos por columna y fila sobre el lago de datos» Lake Formation

3.3 Gobierno y cumplimiento

Módulo: 08.

  • Cumplimiento: model cards de SageMaker AI, linaje de datos con Glue, etiquetado de metadatos para atribuir fuentes, registros de decisiones en CloudWatch Logs.
  • Trazabilidad: Glue Data Catalog para registrar fuentes, metadatos de atribución en el contenido generado, CloudTrail para auditoría.
  • Gobierno organizativo: marcos alineados con políticas, normativas y principios de IA responsable (SCP, guardrails compartidos entre cuentas).
  • Monitorización continua: detección de mal uso, deriva y violaciones de política; alertas y remediación automática; redacción a nivel de token; registro de respuestas.
Si el enunciado dice… Piensa en…
«quién invocó qué modelo y cuándo» CloudTrail
«qué prompt y qué respuesta exactos se produjeron» Model invocation logging (CloudWatch Logs y/o S3)
«documentar el uso previsto, limitaciones y evaluaciones de un modelo» Model cards
«de qué fuentes salió cada dato de entrenamiento o indexado» Glue Data Catalog + linaje + etiquetas
«impedir en toda la organización el uso de ciertos modelos» SCP / políticas IAM por modelId

3.4 IA responsable

Módulo: 08.

  • Transparencia: mostrar razonamiento y fuentes (citas de Knowledge Bases), métricas de confianza en CloudWatch, trazas de agentes.
  • Equidad: métricas de equidad, A/B testing sistemático con Prompt Management y Flows, LLM-as-a-judge para evaluar sesgo a escala.
  • Cumplimiento de políticas: Guardrails configurados según la política, model cards con las limitaciones, Lambda para comprobaciones automáticas.
  • Clarify y A2I están en mantenimiento (cerrados a clientes nuevos); la guía los cita y el examen puede mencionarlos.
Si el enunciado dice… Piensa en…
«los usuarios deben ver en qué se basa la respuesta» Citas de la KB + presentación de evidencias
«comprobar si el modelo responde distinto según el género del nombre» Evaluación de equidad con prompts contrafactuales y LLM como juez
«explicar los pasos que siguió el agente» Trazas del agente (AgentCore Observability / trace)
«revisión humana de respuestas de baja confianza» Flujo con umbral + revisión humana (Step Functions; A2I en la guía)

4.1 Optimización de costes

Módulo: 09.

  • Tokens: estimar y medir (CountTokens, métricas), recortar contexto, limitar maxTokens, comprimir prompts, podar historial.
  • Elección de modelo: relación coste-capacidad, uso escalonado por complejidad, cascada, Intelligent Prompt Routing.
  • Throughput: batch inference (≈ 50 % del precio on-demand), planificación de capacidad, Provisioned Throughput solo si se aprovecha.
  • Caché: prompt caching (partes repetidas del prompt, lectura mucho más barata), caché semántica (preguntas parecidas → misma respuesta, sin invocar el modelo), hash determinista, caché en el edge.
Si el enunciado dice… Piensa en…
«system prompt largo que se repite en todas las llamadas» Prompt caching
«muchos usuarios hacen preguntas casi idénticas» Caché semántica (ElastiCache/OpenSearch/MemoryDB con embeddings)
«procesar 2 millones de documentos, sin prisa» Batch inference
«el 80 % de las consultas son simples» Modelo pequeño + escalado al grande
«historial de chat que crece sin control» Resumir o podar el historial, ventana deslizante

4.2 Rendimiento de la aplicación

Módulo: 09.

  • Latencia percibida: streaming, precomputar consultas previsibles, peticiones en paralelo, modelos latency-optimized (en modelos y regiones concretos).
  • Recuperación: optimizar índices, preprocesar consultas, búsqueda híbrida con puntuación propia.
  • Throughput: gestión de concurrencia, batch, reparto entre regiones con perfiles de inferencia.
  • Parámetros: temperatura baja para respuestas deterministas, alta para creatividad; top-p/top-k; A/B testing para medir mejoras.
  • Recursos: planificación de capacidad en tokens por minuto, escalado automático adaptado al patrón de tráfico.
Si el enunciado dice… Piensa en…
«la primera palabra tarda demasiado en aparecer» Streaming (mide time to first token)
«respuestas inconsistentes para la misma pregunta de clasificación» Temperatura baja (≈ 0)
«un flujo llama a tres modelos independientes en serie» Llamadas en paralelo (Step Functions Parallel)
«superamos los tokens por minuto de la cuota» Aumento de cuota, perfil entre regiones, Provisioned Throughput o Priority tier

4.3 Monitorización

Módulo: 09.

  • Observabilidad integral: métricas operativas (invocaciones, latencia, errores, throttling, tokens de entrada y salida en CloudWatch), trazas (X-Ray, OpenTelemetry con AgentCore Observability), métricas de negocio en paneles (CloudWatch dashboards, Managed Grafana).
  • Métricas propias de IA generativa: uso de tokens, tasa de alucinación, calidad, detección de anomalías en ráfagas de tokens, invocation logs para análisis detallado, Cost Anomaly Detection.
  • Herramientas y agentes: patrones de llamadas, latencia por herramienta, coordinación multiagente, líneas base.
  • Almacenes vectoriales: latencia de consulta, salud del índice, calidad de los datos.
  • Fallos propios: golden datasets para detectar alucinaciones, comparación de salidas (output diffing), trazas del razonamiento.
Si el enunciado dice… Piensa en…
«alertar si el consumo de tokens se dispara» CloudWatch anomaly detection + Cost Anomaly Detection
«ver la latencia de cada paso: API, recuperación, modelo, herramienta» X-Ray / trazas OpenTelemetry
«analizar prompts y respuestas completos» Model invocation logging
«probar el chatbot cada 5 minutos desde fuera» CloudWatch Synthetics
«paneles de negocio para dirección» CloudWatch dashboards / Managed Grafana / Quick Sight

5.1 Sistemas de evaluación

Módulo: 10.

  • Métricas más allá del ML clásico: relevancia, exactitud factual, coherencia, fluidez, fidelidad al contexto.
  • Bedrock Evaluations: automática (métricas programáticas sobre datasets), LLM-as-a-judge, humana (tu equipo), evaluación de RAG (recuperación y recuperación + generación). A/B y canary, comparación multimodelo, coste frente a calidad.
  • Usuarios: pulgares arriba/abajo, valoraciones, anotación.
  • QA continua: regresión de salidas, puertas de calidad en el despliegue.
  • Agentes: tasa de tareas completadas, uso correcto de herramientas, calidad del razonamiento; AgentCore Evaluations.
  • Informes: visualizaciones y comparativas para las partes interesadas.
  • Validación de despliegues: flujos sintéticos, tasa de alucinación, deriva semántica.
Si el enunciado dice… Piensa en…
«evaluar miles de respuestas por criterios subjetivos, rápido y barato» LLM-as-a-judge
«criterios de marca o matices que solo un experto aprecia» Evaluación humana
«medir si el retriever trae los fragmentos correctos» Evaluación de RAG (métricas de recuperación)
«no desplegar un prompt nuevo si baja la calidad» Quality gate en CI/CD con golden dataset
«comparar dos modelos con tráfico real» A/B o canary

5.2 Resolución de problemas

Módulo: 10.

  • Contenido: desbordamiento de la ventana de contexto, truncado (stopReason = max_tokens), chunking dinámico.
  • Integración: ThrottlingException (cuotas, backoff), ValidationException (formato del cuerpo, parámetros del modelo), AccessDeniedException (IAM, SCP, acceso al modelo, región), timeouts.
  • Prompts: pruebas sistemáticas, comparación de versiones, refinamiento.
  • Recuperación: relevancia, calidad de embeddings, deriva, errores de vectorización (mismo modelo de embeddings en ingesta y consulta), chunking.
  • Mantenimiento de prompts: plantillas probadas, CloudWatch Logs para detectar confusión, X-Ray, validación de esquema.
Si el enunciado dice… Piensa en…
«las respuestas se cortan a la mitad» maxTokens demasiado bajo (stopReason max_tokens)
«error al enviar documentos largos» Ventana de contexto: chunking, resumen, recuperar menos
«la búsqueda empeoró tras cambiar el modelo de embeddings» Reindexar todo con el nuevo modelo: no se mezclan espacios vectoriales
«funciona en us-east-1 y da AccessDenied en otra región» Disponibilidad del modelo, perfil de inferencia, SCP con aws:RequestedRegion
«tras actualizar la plantilla, el JSON sale mal a veces» Validación de esquema + comparación de versiones de prompt

Pares que se confunden

RAG frente a fine-tuning frente a destilación (y prompt engineering)

Técnica Qué cambia Cuándo Coste y esfuerzo Palabras clave
Prompt engineering Las instrucciones Siempre primero Mínimo «rápido», «sin infraestructura»
RAG El conocimiento que ve el modelo en cada petición Datos privados o que cambian; necesidad de citar fuentes Medio (índice + recuperación) «documentos internos», «actualizados», «citar fuentes», «sin reentrenar»
Fine-tuning (supervisado o por refuerzo) El comportamiento: estilo, formato, terminología, una tarea concreta Formato o tono que el prompt no consigue; tarea muy específica Alto (datos etiquetados, entrenamiento, Provisioned Throughput o despliegue personalizado) «estilo de la marca», «terminología médica», «formato constante»
Destilación Un modelo pequeño aprende de uno grande (profesor → alumno) Calidad de un modelo grande con coste y latencia de uno pequeño Medio (datos sintéticos generados por el profesor) «reducir coste y latencia manteniendo la precisión»

Regla: conocimiento → RAG; comportamiento → fine-tuning; abaratar un modelo grande → destilación. Se pueden combinar.

Knowledge Bases gestionada frente a la del cliente

Managed Knowledge Base Customer-managed Knowledge Base
Almacén vectorial Lo gestiona Bedrock Lo eliges tú (S3 Vectors, OpenSearch, Aurora pgvector, Neptune Analytics, Pinecone…)
Embeddings y reranking Gestionados, sin coste extra Eliges y pagas el modelo
Conectores S3, SharePoint, Confluence, Google Drive, OneDrive, web crawler, personalizados S3 y personalizados (desde el 30/09/2026 no se crean conectores nuevos de SharePoint, Confluence, Salesforce ni Web Crawler)
Permisos por documento ACL por documento integradas Los implementas tú (metadatos + filtros)
Recuperación Incluye agentic retrieval multi-salto Semántica/híbrida según el almacén
Cuándo LEAST operational overhead, fuentes empresariales, permisos Control del almacén, requisitos de coste o de datos concretos, reutilizar un almacén existente

La distinción existe desde marzo de 2026: una pregunta más antigua puede hablar solo de «Knowledge Bases» con un almacén que elige el cliente.

Bedrock Agents Classic frente a AgentCore (y Flows)

Agents «Classic» AgentCore Bedrock Flows
Qué es Agente gestionado por configuración (action groups, KB) Plataforma para ejecutar y operar agentes de cualquier framework (Runtime, Memory, Gateway, Identity, Observability, Policy, Evaluations, Harness) Flujo determinista de nodos (prompt, KB, Lambda, condición)
Estado Mantenimiento; cerrado a clientes nuevos desde el 30/07/2026 Vigente, alternativa recomendada Vigente
Cuándo Solo si el enunciado lo cita o la empresa ya lo usa Agentes autónomos en producción con herramientas, memoria e identidad Pasos conocidos de antemano, sin decisión autónoma

Guardrails frente a Comprehend frente a Macie

Bedrock Guardrails Amazon Comprehend Amazon Macie
Dónde actúa Entrada y salida de modelos en tiempo real (o ApplyGuardrail) Texto que tú le envías (API de NLP) Datos en reposo en S3
Qué hace Filtros de contenido, prompt attack, temas denegados, palabras, PII (bloquear/enmascarar), grounding, Automated Reasoning PII, entidades, sentimiento, idioma, toxicidad, clasificación personalizada Descubre y clasifica datos sensibles en buckets, genera hallazgos
Cuándo Proteger una aplicación de IA generativa Preprocesar o enriquecer texto, pipelines de NLP Auditar qué PII hay en el lago de datos antes de indexarlo

Ojo: la Prompt Safety Classification de Comprehend está en mantenimiento; para ataques de prompt, Guardrails.

Provisioned Throughput frente a niveles de servicio frente a batch

Opción Cómo se paga Para qué Trampa
On-demand Standard Por token Tráfico variable Cuotas de tokens por minuto
Priority Por token con prima Latencia prioritaria en picos Más caro que Standard
Flex Por token, más barato Cargas que toleran más latencia Menor prioridad
Reserved Compromiso de 1 o 3 meses (vía equipo de cuenta) Capacidad garantizada en tokens por minuto Compromiso mínimo
Provisioned Throughput Por hora (Model Units), sin compromiso o a 1/6 meses Modelos personalizados, throughput constante garantizado Se cobra aunque no se use; no funciona con perfiles de inferencia
Batch inference ≈ 50 % del on-demand Grandes volúmenes sin prisa (S3 → S3) Asíncrono; no admite tool calling ni prompt caching (structured outputs sí figura como compatible)
Cross-Region inference Precio de la región origen (global ≈ 10 % más barato) Más capacidad y resiliencia Global puede sacar datos de la geografía

InvokeModel frente a Converse

InvokeModel / InvokeModelWithResponseStream Converse / ConverseStream
Formato Cuerpo JSON específico de cada modelo Formato único para todos los modelos que lo soportan
Conversación La gestionas tú en el cuerpo Lista de mensajes con roles y system prompt
Tool use, guardrails Según el modelo Integrados de forma uniforme
Cuándo Funciones exclusivas de un modelo, embeddings, imágenes Chat, cambiar de modelo sin reescribir, herramientas

Prompt Management frente a Flows frente a Step Functions

Prompt Management Bedrock Flows (Prompt Flows) Step Functions
Qué gestiona Prompts: plantillas, variables, versiones, variantes Cadenas de prompts y nodos de IA en un constructor visual Cualquier flujo de AWS: reintentos, esperas, humanos, paralelismo
Cuándo Gobernar y reutilizar prompts Flujos de IA generativa sin código Orquestación empresarial, aprobaciones, circuit breakers, trabajos largos

SageMaker AI frente a Bedrock

Amazon Bedrock Amazon SageMaker AI
Modelo de uso API serverless de modelos fundacionales Plataforma de ML: entrenar, ajustar y desplegar en instancias
Infraestructura Ninguna que gestionar Eliges instancias, escalado, contenedores
Personalización Fine-tuning, destilación, Custom Model Import Control total (LoRA, entrenamiento, contenedores propios, Neo)
Cuándo Por defecto; LEAST operational overhead Modelo no disponible en Bedrock, control fino de la inferencia, requisitos de hardware

S3 Vectors frente a OpenSearch frente a Aurora pgvector

S3 Vectors OpenSearch Service / Serverless Aurora PostgreSQL + pgvector
Fuerte en Coste mínimo, escala enorme, sin servidores Búsqueda híbrida, filtros ricos, latencia muy baja, analítica Unir vectores con datos relacionales, SQL, transacciones
Coste Céntimos por GB-mes y por consulta OCU por hora (Serverless) o instancias ACU por hora (Serverless v2 puede pausar a 0 ACU)
Cuándo Datos grandes con consultas moderadas, presupuesto ajustado Alta concurrencia, relevancia avanzada El equipo ya vive en PostgreSQL

Además: Neptune Analytics para GraphRAG, ElastiCache/MemoryDB para caché semántica de baja latencia, DynamoDB para metadatos e historial (y, desde el 05/08/2026, con búsqueda vectorial nativa, aunque no como almacén de Knowledge Bases).

Evaluación automática frente a LLM como juez frente a humana

Automática (programática) LLM-as-a-judge Humana
Cómo Métricas calculadas sobre un dataset con respuestas de referencia Otro modelo puntúa con criterios (corrección, completitud, nocividad…) Personas valoran según instrucciones
Fuerte en Tareas con respuesta conocida, barata y repetible Criterios subjetivos a escala, rápido Matices, marca, dominios expertos
Débil en Calidad abierta Sesgos del juez; conviene calibrar con humanos Lenta y cara

Para agentes: AgentCore Evaluations. Para RAG: evaluación de recuperación y de recuperación + generación.

CloudTrail frente a invocation logging frente a CloudWatch frente a X-Ray

Servicio Responde a
CloudTrail ¿Quién llamó a qué API y cuándo? (auditoría)
Model invocation logging ¿Qué prompt y qué respuesta exactos? (desactivado por defecto; a CloudWatch Logs y/o S3)
CloudWatch ¿Cuánto? Métricas de invocaciones, latencia, tokens, errores; alarmas
X-Ray / OpenTelemetry ¿Dónde se va el tiempo en una petición que cruza varios servicios?

Prompt caching frente a caché semántica

  • Prompt caching (Bedrock): el modelo reutiliza el procesamiento de un prefijo idéntico (system prompt, documento largo). La llamada se hace igualmente, pero los tokens leídos de caché cuestan mucho menos y la latencia baja.
  • Caché semántica (la construyes tú): si una pregunta se parece a otra ya respondida, devuelves la respuesta guardada sin llamar al modelo. Ojo con datos personalizados o que caducan.

Kendra y Q Business frente a Knowledge Bases y Amazon Quick

Kendra y Q Business están cerrados a clientes nuevos desde julio de 2026. Alternativas: Managed Knowledge Base (búsqueda empresarial para aplicaciones y agentes) y Amazon Quick (asistente empresarial listo para usar). Si el examen describe «un asistente empresarial listo para usar, sin desarrollo», la respuesta histórica era Q Business.

Perfil de inferencia geográfico frente a global

  • Geográfico (eu.): enruta dentro de la UE. Úsalo si hay residencia de datos.
  • Global (global.): cualquier región comercial, más capacidad y unos 10 % más barato; no sirve si los datos no pueden salir de la geografía.

Strands Agents frente a Agent Squad frente a MCP

  • Strands Agents: SDK para construir el agente (modelo + herramientas + bucle).
  • Agent Squad: orquestador de varios agentes que enruta cada petición al especialista.
  • MCP: protocolo estándar para exponer herramientas y datos a cualquier agente. No es un framework de agentes.

Q Developer frente a Kiro

La guía cita Amazon Q Developer para productividad; sus plugins de IDE están en sunset (fin de soporte el 30/04/2027) y AWS recomienda Kiro. Q Developer en la consola y en apps de chat sigue.

Servicios en mantenimiento: cómo razonar en el examen

La guía oficial sigue citando servicios que, desde junio-julio de 2026, están en mantenimiento (no aceptan clientes nuevos). Fuente: Services in Maintenance.

Servicio de la guía Estado (01/10/2026) Alternativa actual
Bedrock Agents (Classic) Cerrado a clientes nuevos desde el 30/07/2026 AgentCore
Amazon Kendra Cerrado a clientes nuevos desde el 30/07/2026 Managed Knowledge Base
Amazon Q Business / Q Business Apps Cerrado a clientes nuevos Amazon Quick
Amazon Q Developer (IDE) Sunset, fin de soporte 30/04/2027 Kiro
Augmented AI (A2I) Mantenimiento; cerrado a clientes nuevos desde el 30/07/2026 Flujos humanos con Step Functions
SageMaker Clarify, Ground Truth, Model Monitor Mantenimiento; cerrados a clientes nuevos desde el 30/07/2026 Bedrock Evaluations, fmeval y SHAP, soluciones open source de monitorización con CloudWatch y Quick Sight
AWS App Runner Cerrado a clientes nuevos desde el 30/04/2026 Amazon ECS Express Mode

Cómo responder:

  1. Si la pregunta describe una empresa que ya usa el servicio, respóndela con él sin problema.
  2. Si una opción con el servicio cerrado y otra con su alternativa cumplen igual, piensa en lo que pide la pregunta: el examen se actualizó en marzo de 2026 para añadir AgentCore, pero las preguntas pueden ser anteriores al cierre. Elige por requisitos, no por la fecha de cierre.
  3. No descartes una opción solo porque el servicio está en mantenimiento: el examen evalúa conceptos, y AWS no ha anunciado cambios en la guía por estos cierres.

Inscripción y día del examen

Todo el detalle está en El examen. Lista de comprobación:

  • Cuenta de AWS Certification con nombre idéntico al de tu documento.
  • Adaptación ESL +30 min pedida antes de reservar (Request Exam Accommodations → ESL +30 MINUTES).
  • Reserva en Pearson VUE (centro o online), en inglés.
  • Vale del 50 % del SAA aplicado al pagar (150 USD en lugar de 300).
  • Si es online: System Test de OnVUE en el mismo ordenador y red, el día antes otra vez.
  • Documento de identidad en vigor (en centro, AWS pide dos documentos o uno principal y uno secundario; online, uno principal).

El día del examen:

  • Duerme bien. Nada de temario nuevo las últimas 24 horas: solo la columna «Regla que me llevo» y las tarjetas de este módulo.
  • Llega 15-30 minutos antes (online: check-in desde 30 minutos antes). Con más de 15 minutos de retraso pierdes el examen.
  • Usa la pantalla de instrucciones para respirar y anotar tus puntos de control de tiempo.
  • El resultado llega a tu cuenta en un máximo de 5 días hábiles. La insignia de Credly suele llegar por correo.

Siguiente paso: Solutions Architect – Professional

Tu ruta es SAA-C03 → AIP-C01 → Solutions Architect – Professional. Datos verificados el 01/10/2026 en la página de la certificación:

  • El SAP-C02 se puede hacer hasta el 17/11/2026. La inscripción del SAP-C03 se abre el 27/10/2026.
  • 75 preguntas, 180 minutos, 300 USD (150 con el vale del 50 % que te dará el AIP-C01).
  • Disponible en inglés y español (Latinoamérica), entre otros.
  • Aprobarlo renueva tu SAA-C03.

Lo que te llevas del AIP-C01 a la SAP: el hábito de leer enunciados largos, los calificadores en inglés, y todo lo de integración, seguridad, observabilidad y costes. Lo nuevo será multicuenta (Organizations, Control Tower), redes híbridas, migraciones y continuidad de negocio a gran escala. Deja pasar unas semanas tras el AIP-C01, actualiza LinkedIn con la insignia y los diseños del lab 19, y empieza la SAP con la guía del SAP-C03 cuando se publique.

Trampas típicas del examen

  • «Documentos que cambian a diario» + fine-tuning → error: es RAG con sincronización.
  • «Los datos no pueden salir de la UE» + perfil global → error: perfil geográfico eu. o modelo in-Region.
  • «Tráfico esporádico» + Provisioned Throughput → error: on-demand; PT se cobra por hora.
  • «Ver el contenido del prompt» + CloudTrail → error: model invocation logging.
  • «Filtrar respuestas del chatbot» + Macie → error: Guardrails (Macie analiza S3).
  • «Cambiar de modelo sin desplegar» + variable de entorno de Lambda → incompleto: requiere redesplegar; AppConfig o Prompt Management.
  • «Procesar un millón de registros esta noche» + llamadas on-demand en bucle → caro y lento: batch inference.
  • «Salida en JSON para un sistema posterior» + solo «pedirlo amablemente en el prompt» → frágil: esquema + validación.
  • «Cambié el modelo de embeddings y la búsqueda falla» → hay que reindexar todo.
  • «Agente que no para» → máximo de iteraciones y timeouts, no un modelo más grande.
  • «Evaluar a escala criterios subjetivos» + evaluación humana → lenta y cara; LLM como juez (calibrado con muestras humanas).
  • «Permisos por documento en el asistente» + un índice por usuario → inviable; ACL por documento o filtros de metadatos con la identidad del usuario.

Resumen

  • Esta semana: simulacros 2 y 3 en condiciones reales, cuaderno de errores y repaso dirigido. Objetivo: 80 % en el ensayo general.
  • 2,4 minutos por pregunta (2,8 con ESL). Lee la pregunta final primero, busca requisitos duros, descarta, marca y sigue.
  • Los calificadores en inglés (LEAST operational overhead, MOST cost-effective…) deciden entre dos opciones válidas.
  • Conocimiento → RAG; comportamiento → fine-tuning; abaratar → destilación, modelo pequeño, caché, batch.
  • Seguridad en capas: Guardrails (entrada y salida), Comprehend/Macie (PII), VPC endpoints, KMS, IAM; auditoría con CloudTrail + invocation logs.
  • AgentCore sustituye a Agents Classic; Managed Knowledge Base a Kendra; Quick a Q Business; Kiro a Q Developer en el IDE. El examen puede nombrar los antiguos.
  • Pide ESL antes de reservar, usa el vale del 50 % y sigue con el SAP-C03.

Cobertura del temario

Este módulo repasa todos los task statements; la teoría completa está en los módulos 1-10.

Task statement Skills Sección de este módulo
1.1 1.1.1-1.1.3 Repaso por task statement → 1.1; lab 19
1.2 1.2.1-1.2.4 1.2; pares «SageMaker AI frente a Bedrock», «geográfico frente a global»
1.3 1.3.1-1.3.4 1.3
1.4 1.4.1-1.4.5 1.4; par «S3 Vectors frente a OpenSearch frente a Aurora pgvector»
1.5 1.5.1-1.5.6 1.5; pares «RAG frente a fine-tuning», «Knowledge Bases gestionada frente a la del cliente»
1.6 1.6.1-1.6.6 1.6; par «Prompt Management frente a Flows frente a Step Functions»
2.1 2.1.1-2.1.7 2.1; pares «Agents Classic frente a AgentCore», «Strands frente a Agent Squad frente a MCP»
2.2 2.2.1-2.2.3 2.2; par «Provisioned Throughput frente a niveles de servicio frente a batch»
2.3 2.3.1-2.3.5 2.3
2.4 2.4.1-2.4.4 2.4; par «InvokeModel frente a Converse»
2.5 2.5.1-2.5.6 2.5; par «Q Developer frente a Kiro»
3.1 3.1.1-3.1.5 3.1; par «Guardrails frente a Comprehend frente a Macie»
3.2 3.2.1-3.2.3 3.2
3.3 3.3.1-3.3.4 3.3; par «CloudTrail frente a invocation logging…»
3.4 3.4.1-3.4.3 3.4
4.1 4.1.1-4.1.4 4.1; par «prompt caching frente a caché semántica»
4.2 4.2.1-4.2.6 4.2
4.3 4.3.1-4.3.6 4.3
5.1 5.1.1-5.1.9 5.1; par «evaluación automática frente a LLM como juez frente a humana»
5.2 5.2.1-5.2.5 5.2; trampas típicas

Practica lo aprendido

Lab
Diseño de soluciones de IA generativa: de los requisitos al coste por tokens
⏱ 3-4 h (1-1,5 h por escenario)0 USD: no se crea ningún recurso en AWS
Hacer el test (34 preguntas)Repasar tarjetas (42)

Documentación oficial para ampliar