DEV Community: Antonia Navarrete

AWS Solutions Architect Associate: La Guía Que Pasé el Examen y No Quería Olvidar

Antonia Navarrete — Tue, 25 Aug 2026 16:37:35 +0000

AWS Solutions Architect Associate: La Guía Que Pasé el Examen y No Quería Olvidar

Hace tres meses estaba aquí mismo, dudando si realmente podría pasar el examen de AWS Solutions Architect. Hoy puedo decirte que no solo lo pasé, sino que aprendí muchísimo en el camino. Y lo mejor: ahora sé exactamente qué información es real y cuál es solo ruido de internet.

Este post es para ti si estás pensando en certificarte, si ya empezaste y te sientes abrumado, o si simplemente quieres saber qué se esconde detrás de este examen que todos hablan pero pocos explican honestamente.

No voy a decirte "es fácil" ni "es imposible". Voy a decirte exactamente cómo es, qué esperar, y cómo prepararte sin perder la cabeza.

📊 Primero: Los Datos Que Nadie Habla

¿Cuántas personas lo pasan realmente?

AWS no publica la tasa oficial de aprobación (típico de ellos, ¿verdad?). Pero según múltiples comunidades, reportes de LinkedIn y fuentes de la industria, estamos hablando de un 60-65% de aprobación en primer intento.

¿Qué significa esto? De cada 100 personas que lo intentan, 35-40 no lo pasan. No es un examen que puedas tomar en viernes después de trabajo.

Pero aquí viene lo interesante: la mayoría de los que fallan no lo hace por falta de inteligencia, sino por mala preparación. Eso significa que si haces lo correcto, tus probabilidades suben enormemente.

El Formato Real del Examen

65 preguntas en total
130 minutos para responder (eso es ~2 minutos por pregunta)
50 preguntas con puntuación + 15 preguntas experimentales sin puntuación
Puntuación de 100-1000, siendo 720 la puntuación mínima para aprobar
Modalidad: Opción múltiple (4 opciones por pregunta)

Aquí viene el dato visceral: Esas preguntas no son "¿Qué es EC2?" Son párrafos de 5-8 líneas describiendo un escenario empresarial complicado, y tú tienes que elegir la MEJOR opción de 4 opciones que todas parecen correctas.

Ejemplo real que vi:

"Una empresa multinacional tiene aplicaciones en 5 regiones de AWS. Necesitan replicar datos en tiempo real entre regiones, con consistencia fuerte, pero mantener costos bajos. Usan EC2 con aplicaciones legacy que no pueden cambiar. ¿Cuál es la solución más costo-efectiva?"

Las opciones eran: DynamoDB Global Tables, Aurora Global Database, EC2 con rsync, RDS Multi-Region Failover. Todas tienen sentido, pero solo una es LA respuesta en ese contexto específico.

El "Secreto" de las Preguntas Atrapasueños

Hay aproximadamente 3-4 preguntas diseñadas deliberadamente para confundirte. AWS es malévolo así. Entienden que si haces 61 de 65 preguntas, pasas. Pero van a intentar que falle en esas 4.

Las trampas comunes:

Dos servicios que hacen "casi lo mismo" (CloudFront vs S3 Transfer Acceleration)
Un objetivo que requiere dos soluciones (alta disponibilidad + bajo costo)
Vocabulario técnico similar pero significado diferente (Multi-AZ vs Multi-Región)

La diferencia entre pasar y no pasar a veces está en entender matices de vocabulario en inglés que cambian todo.

🚫 Las 7 Cosas Que NADIE Te Cuenta (Pero Deberías Saber)

1. El Examen No Mide lo Que Piensas

La mayoría cree que es un test de conocimiento técnico. Está equivocado.

Es un test de criterio empresarial y toma de decisiones bajo restricciones.

AWS no pregunta "¿Cómo funciona Auto Scaling?" sino "¿Cómo escalarías una aplicación que tiene picos impredecibles, presupuesto limitado y debe tener latencia <50ms en todo el mundo?"

La diferencia es fundamental. El primero se resuelve con Wikipedia. El segundo requiere que pienses como un arquitecto de verdad.

2. Hay ~25-30 Servicios que Realmente Importan (No 200)

AWS tiene más de 200 servicios. Es una cifra que te asusta a propósito.

La realidad: El examen se enfoca en estos:

Compute:

EC2 (instancias, tipos, AMIs, key pairs)
Lambda (triggers, concurrencia, VPC)
ECS/Fargate (containers, task definitions)
Elastic Beanstalk (PaaS, deployment)

Storage:

S3 (buckets, versioning, lifecycle, replicación)
EBS (volúmenes, snapshots, IOPS)
EFS (NFS, shared storage)
Glacier (archiving)
FSx (Windows/Lustre)

Database:

RDS (Multi-AZ, read replicas, backup)
DynamoDB (NoSQL, particiones, scaling)
Aurora (MySQL/PostgreSQL)
ElastiCache (Redis/Memcached)
Redshift (data warehouse)

Networking:

VPC (subnets, route tables, NAT, bastions)
Security Groups (stateful firewall)
NACLs (stateless firewall)
Route 53 (DNS, routing policies)
CloudFront (CDN)
ELB/ALB/NLB (load balancers)
Direct Connect (conexión dedicada)

Management & Monitoring:

IAM (policies, roles, permissions)
CloudWatch (métricas, logs, alarms)
CloudTrail (auditoría)
CloudFormation (IaC)
Systems Manager (patch management)
Auto Scaling (políticas)

Security:

KMS (key management)
Secrets Manager
Cognito (auth)
Shield (DDoS)
WAF (web application firewall)

Eso es. No necesitas saber SageMaker, Kinesis, AppSync o Lambda@Edge para aprobar.

3. IAM Es Más Importante Que Tu Próxima Respiración

Aproximadamente el 15-20% del examen es IAM. Y no hablo de "crear un usuario". Hablo de:

Policies (inline vs managed, deny vs allow, effect vs action)
Trust Relationships (quién puede asumir un rol)
Resource-Based Policies (permisos en buckets S3, colas SQS, etc.)
Permission Boundaries (límites de permisos)
Rol Assumption (cómo un usuario, EC2 o Lambda asume un rol)

La trampa: IAM es conceptualmente simple pero brutalmente específico. Una sola palabra en una policy puede cambiar todo.

Ejemplo real que vi:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::mybucket/*"
}

La primera es un riesgo de seguridad masivo. La segunda es lo correcto. El examen te va a preguntar cuál es la respuesta más segura.

4. Las Preguntas Tienen un Patrón Oculto

Después de hacer 200+ preguntas prácticas, noté que AWS tiene patrones sutiles:

Si el escenario menciona "reducir costos", la respuesta generalmente involucra instancias reservadas, Spot o cambio de tipo de BD.
Si dice "99.99% uptime", necesitas Multi-AZ mínimo, o multi-región si es crítico.
Si menciona "aplicación legacy", olvídate de migraciones complejas; probablemente EC2.
Si habla de "desarrolladores necesitan libertad", piensa en Lambda, Fargate, menos en EC2.
Si es "máxima seguridad", probablemente VPC privada, bastión, KMS, todo encriptado.

Una vez que ves el patrón, muchas preguntas se resuelven casi solas.

5. S3 y RDS Son el 40% del Examen

No exagero. Espera al menos 25-26 preguntas sobre estos dos servicios.

S3 Es Mucho Más Que Un Bucket:

Versioning y MFA Delete
Lifecycle policies (cómo los objetos envejecen)
Replication (SameRegion o CrossRegion)
Access Control (ACLs, bucket policies, public access blocks)
Hosting estático
Presigned URLs
S3 Transfer Acceleration
S3 Intelligent-Tiering

RDS Es Arquitectura De Base De Datos:

Multi-AZ (qué pasa en un failover)
Read Replicas (cómo funcionan, dónde pueden estar)
Backup y Recovery (RTO/RPO)
Parameter Groups (configuración de la BD)
Option Groups (plugins)
Enhanced Monitoring
Performance Insights

6. VPC Te Hará Sudar Frío (Pero Es Más Fácil De Lo Que Parece)

VPC es donde muchos fallan porque parece complicado.

Aquí está la verdad: VPC es solo networking de primaria en la nube.

Subnet = Rango de IPs en una AZ
Security Group = Firewall por instancia (STATEFUL)
NACL = Firewall por subnet (STATELESS)
Route Table = "Si el tráfico va a X, mandalo a Y"
Bastión = Una instancia EC2 en subnet pública que usas como "portero" para acceder a instancias en subnets privadas
NAT Gateway = Permite que instancias privadas accedan a internet

La pregunta típica de VPC en el examen: "Tenemos 3 EC2s en subnet privada que necesitan acceso a un API externo. ¿Cómo lo hacemos sin exponerlas a internet?"

Respuesta: NAT Gateway en subnet pública + route table que dirige todo el tráfico saliente a través del NAT.

7. El Examen Valida Experiencia, No Solo Lectura

Esto es lo más importante.

Puedo ver a alguien que memorizó 50 PDFs de AWS pero nunca ha visto una arquitectura real en producción. El examen los atrapa.

Porque el examen pregunta: "¿Cuál es el trade-off REAL aquí?" Y la respuesta no es textbook; es experiencial.

Por ejemplo:

"Una startup tiene presupuesto limitado pero necesita escalar. La opción A es Auto Scaling con EC2, opción B es Lambda. ¿Cuál?"

Si nunca usaste Lambda, podrías pensar "Lambda es más barato" ✗
La realidad: Lambda es barato hasta que tienes 1000 invocaciones/segundo. Entonces EC2 reservado + Auto Scaling es más barato. O es un mix. Depende del patrón de tráfico.

Esto no está en Wikipedia. Esto es experiencia.

Ahora que entiendes estos conceptos fundamentales, vamos a desglosar exactamente qué AWS pregunta en cada uno de los 6 dominios del examen. Esto es lo que necesitas dominar para pasar.

📚 Los 6 Dominios Del Examen (Desglosados Profundamente)

AWS divide el examen en 6 dominios. Cada uno tiene un peso diferente. Aquí está el breakdown honesto:

Dominio 1: Diseño de Arquitecturas Resilientes (~26%)

Qué significa: ¿Puedo diseñar una aplicación que siga funcionando cuando todo se desmorona?

Temas clave:

Disponibilidad y Tolerancia a Fallos
- Multi-AZ: Qué pasa cuando una AZ se cae
- Multi-Región: Cómo replicar todo a otra región
- RTO (Recovery Time Objective): "Cuánto tiempo tardas en recuperarte"
- RPO (Recovery Point Objective): "Cuántos datos pierdes"

Ejemplo: Un banco necesita RTO <1 minuto y RPO = 0 (no puede perder ni un peso). Eso significa Aurora Multi-Región con replicación síncrona, multi-AZ, y probablemente Active-Active setup.

Scaling
- Vertical Scaling: Más potente la misma máquina (limitado, no es elástico)
- Horizontal Scaling: Más máquinas (elástico, lo que AWS ama)
- Auto Scaling: Reglas automáticas basadas en métricas

Trampa: Auto Scaling no es instantáneo. Hay "warm-up time". Si un servidor tarda 2 minutos en estar listo, tus 30 nuevos servidores no van a estar listos en 30 segundos.

Load Balancing
- ALB (Application Load Balancer): Capa 7, basado en URL/hostname/headers
- NLB (Network Load Balancer): Capa 4, ultra-rápido, millones de requests/segundo
- CLB (Classic Load Balancer): Legacy, no lo uses
Disaster Recovery
- Backup & Restore: "Backup cada hora, recupera en 4 horas" (RTO 4 horas)
- Pilot Light: Un servidor standby listo para tomar carga (RTO 15 min)
- Warm Standby: Servidores standby con capacidad parcial (RTO 5 min)
- Active-Active: Tráfico en ambas regiones simultáneamente (RTO = 0)

Preguntas Reales:

"¿Cómo haces failover automático de RDS?" → Multi-AZ + Route 53 health checks
"¿Cómo replicas una BD con 0 RPO?" → Aurora Global Database con replicación síncrona (o DynamoDB Global Tables)

Dominio 2: Arquitecturas de Alto Rendimiento (~24%)

Qué significa: ¿Cómo hago que mi aplicación sea rápida?

Temas clave:

Selección de Instancias
- General Purpose (t3, m5): Lo más flexible, "cuando no sabes qué elegir"
- Compute Optimized (c5, c6): CPU-heavy, machine learning, renderizado
- Memory Optimized (r5, x1): In-memory databases, caches, analytics
- Storage Optimized (i3, h1): NoSQL, data warehouses
- GPU (p3, g4): Deep learning, video rendering

Errores comunes:

Elegir t3 (burstable) para aplicaciones de alta carga
Olvidar que t3 es bueno solo para cosas intermitentes
Si necesitas CPU consistente, los t3 son una mala idea
- Caching
ElastiCache: Redis (estructuras complejas, persistencia) vs Memcached (simple, ultrarrápido)
CloudFront: CDN, cachea objetos cerca del usuario
DynamoDB DAX: Cache especialmente para DynamoDB (microsegundos de latencia)
- Optimización de BD
Read Replicas en RDS: Distribuye lecturas
DynamoDB: Diseño de partition keys (super importante)
Redshift: Para queries analíticas masivas
Aurora: Superior a RDS en rendimiento
- Networking
CloudFront para contenido estático/dinámico
Route 53 geolocation: Redireccionar usuarios a endpoint más cercano
Direct Connect: Conexión dedicada a AWS (mejor latencia)

Preguntas Reales:

"¿Cómo mejoro latencia de lecturas en RDS?" → Read replicas
"¿Qué caché elegir para valores simples de corta vida?" → Memcached
"¿Cómo sirvo imágenes a usuarios globales rápidamente?" → S3 + CloudFront

Dominio 3: Arquitecturas Seguras (~25%)

Qué significa: ¿Cómo evito que alguien robe mis datos?

Temas clave:

IAM (El Rey)
- Principio de Least Privilege: "Dale a cada usuario SÓ LO que necesita"
- Roles vs Users: Los usuarios son para personas, roles para servicios
- Trust Relationships: "¿Quién puede asumir este rol?"
- Cross-Account Access: Un rol en Account A que puede hacer cosas en Account B

Ejemplo real comparando dos IAM Policies:

❌ INSEGURA (Demasiado permisiva):

  {
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }

Permite TODO en S3. Es un riesgo de seguridad masivo. Nunca hagas esto.

✅ CORRECTA (Least Privilege):

  {
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::mybucket/*"
  }

Solo permite LEER objetos de un bucket específico. El examen siempre va a elegir la opción más segura.

Ejemplo de Cross-Account:

  Necesito que Lambda (en Account A) lea un bucket S3 (en Account B).

  Paso 1: En Account B, creo un bucket policy que permite Account A.
  Paso 2: En Account A, creo un IAM role con permisos s3:GetObject.
  Paso 3: Asocio ese role a Lambda.

Networking Security
- Security Groups: Whitelisting (solo permite lo explícito)
- NACLs: Puede tener reglas allow Y deny
- VPC Flow Logs: "Espía" el tráfico en la red
- VPC Endpoints: Acceder a AWS services sin salir de la VPC
Encriptación
- At Rest (reposo): Los datos almacenados están encriptados
- In Transit (tránsito): Los datos viajando están encriptados (TLS)
- KMS: Administras las keys
- HSM: Hardware para máxima seguridad
DDoS & WAF
- Shield: Protección básica contra DDoS (free en todos)
- Shield Advanced: Protección más fuerte
- WAF: Firewall para aplicaciones (reglas a nivel de aplicación)
Autenticación & Autorización
- Cognito: Maneja autenticación de usuarios finales
- SSO: Integración con directorios corporativos
- Temp Credentials: Mejor que access keys permanentes

Preguntas Reales:

"¿Cómo accede una aplicación en EC2 a un bucket S3 sin access keys?" → IAM Role en EC2
"¿Cómo restrinjo el acceso a RDS solo desde mi aplicación?" → Security Group que solo permite tu app
"¿Cuál es el máximo tiempo que debería vivir una temporary credential?" → 12 horas (o menos)

Dominio 4: Arquitecturas de Bajo Costo (~19%)

Qué significa: ¿Cómo hago todo lo anterior pero gastando menos?

Temas clave:

Modelos de Pricing
- On-Demand: "Pagas lo que usas, sin compromisos"
- Reserved Instances: "Te comprometes 1-3 años, descuento de 40-70%"
- Spot Instances: "Compras lo que AWS no está usando, descuento de 70-90% pero te puede sacar"
- Savings Plans: Flexible, descuento por hora

Estrategia típica:

Workload base = Reserved Instances
Picos predecibles = On-Demand
Picos impredecibles tolerables a interrupciones = Spot
- Right-Sizing
Usar instancias del tamaño correcto (no sobre-provisionar)
Terminar instancias que no usas
Usar t3.micro/small para dev/test
- Storage Optimization
Lifecycle policies: Mover datos antiguos a Glacier (90% más barato)
EBS: No mantener snapshots innecesarios
S3 Intelligent-Tiering: Mueve automáticamente objetos según acceso
- Database
Aurora serverless: Pagas por computación usada
DynamoDB on-demand vs provisioned (depende del patrón de uso)
- Networking
Data Transfer: Es costoso. Minimiza movimiento entre regiones.

Preguntas Reales:

"¿Cómo reducimos costos en un 50% sin afectar uptime?" → Reserved Instances + Spot para picos
"¿Qué hacer con 5 años de backups de S3?" → Lifecycle policy a Glacier

Dominio 5: Operaciones Excelentes (~16%)

Qué significa: ¿Cómo ejecuto y monitoreo todo esto?

Temas clave:

Observabilidad
- CloudWatch: Métricas, logs, alarms
- CloudTrail: "Quién hizo qué y cuándo" (auditoría)
- X-Ray: Tracing de requests distribuidos
- VPC Flow Logs: Tráfico de red
Infrastructure as Code
- CloudFormation: Templates que crean recursos
- Beneficio: Repeatable, versionable, testeable
Patch Management
- AWS Systems Manager Patch Manager: Aplica patches automáticamente
- AMIs de Golden (imágenes pre-patcheadas)
Configuration Management
- Parameter Store: Almacena configuración (contraseñas, URLs, etc.)
- Secrets Manager: Similar pero para secretos

Preguntas Reales:

"¿Cómo monitoreo si una instancia está healthy?" → CloudWatch alarms + Auto Scaling health checks
"¿Quién deletó mi bucket S3?" → CloudTrail

Dominio 6: Diseño Cost-Optimized (~Integrado en todo)

Lo interesante es que AWS integra cost optimization en todos lados. No es separado, es transversal.

La filosofía: "La solución correcta debe ser también la más barata (o al menos tener buena relación costo-beneficio)."

🎓 Mi Estrategia de Estudio Que Funcionó (Mes 1 Completo)

Semana 1: Fundamentos (Teoría Pura)

Objetivo: Entender qué es cada servicio y por qué existe.

Recursos:

Coursera - AWS Fundamentals (12-15 horas de video)
- Excelente para principiantes
- Cubre todos los servicios en profundidad
- Precio: $39/mes o incluido si tienes suscripción educativa
YouTube - Adrian Cantrill (AWS Certified Solutions Architect Associate)
- Gratuitamente puedes ver muchos videos introductorios
- Sus explicaciones son brutales de buenas
- Luego puedes comprar su curso en Udemy ($15)

Acción concreta:

Ve 2-3 videos por día
Toma notas en 3 formatos:
- Notas de texto (conceptos)
- Diagramas dibujados a mano (arquitectura)
- Preguntas que tengo (para después)

Meta: Después de esta semana deberías poder explicar en 5 minutos qué hace EC2, S3, RDS, Lambda, VPC.

Semana 2: Profundidad + Diagramas

Objetivo: Pasar de "sé qué es" a "sé cuándo usarlo".

Recursos:

A Cloud Guru (Ahora Pluralsight) - AWS Solutions Architect Course
- Incluye labs interactivos (creas cosas reales)
- Sandbox gratis para practicar
- $29/mes, pero vale cada centavo
Adrian Cantrill - Solutions Architect Course (Udemy) ($15 en oferta)
- 40+ horas de contenido ultra-detallado
- Incluye labs prácticos en AWS
- Diagrama cada concepto
AWS Well-Architected Framework Whitepaper
- Gratis en AWS website
- Lee los 5 pilares: Excelencia Operativa, Seguridad, Confiabilidad, Eficiencia de Rendimiento, Optimización de Costos

Acción concreta:

Haz 3-4 labs prácticos (en sandbox)
- Crea una VPC con 2 subnets, security groups, NAT
- Lanza EC2 + RDS con Auto Scaling
- Configura CloudFront con S3
Dibuja diagramas de cada escenario
Lee 1 whitepaper

Meta: Deberías poder diseñar una arquitectura simple (3-4 servicios) en una servilleta y explicar por qué.

Semana 3: Simulacros + Análisis Brutal

Objetivo: Ahora que sabes teoría, ¿puedes pasar preguntas?

Recursos - Simulacros (MUY IMPORTANTE):

Jon Bonso - AWS Solutions Architect Practice Exams (Udemy) ⭐⭐⭐⭐⭐
- Precio: $15 (casi siempre en oferta)
- 780 preguntas en 6 simulacros
- Explicaciones detalladas después de cada pregunta
- La dificultad es SIMILAR al examen real
- Yo diría: Este es el más cercano al examen real
ExamPro - Free Practice Exams
- 300+ preguntas gratis
- Buena calidad
- Interfaz intuitiva
- Freemium (parte paga)
AWS Official Sample Exam
- Disponible en AWS Training & Certification
- 40 preguntas gratis
- Muy representativas
Tutorial Dojo - AWS Practice Exams
- 1100+ preguntas
- Muy detalladas
- $15 en oferta

Plan de Acción:

Día 1-2: Primer simulacro Jon Bonso (65 preguntas). No importa si sacas 50%.
Después de cada simulacro:
- Revisa TODAS las preguntas, no solo las que fallaste
- Lee cada explicación 2 veces
- Anota las que te sorprendieron
- Dibuja diagramas de las que involucraban arquitectura
Día 4-5: Segundo simulacro (después de estudiar las áreas débiles)
Día 7: Tercer simulacro

Meta: Progresión típica en simulacros:

Simulacro 1: 60-70%
Simulacro 2: 70-75%
Simulacro 3: 75-80%
Si llegas a 80%+ en 3 simulacros, estás listo para el real

Yo alcancé: 71%, 76%, 82%. Pasé el examen real con 82%.

Semana 4: Especialización + Repaso

Objetivo: Refuerza las áreas donde flaqueas. No estudies lo que ya sabes.

Análisis de Debilidades:
De tus simulacros, identifica:

Las 3 áreas donde sacas peor puntaje
Los 2-3 servicios que no entiendes

Recursos Específicos:

Para IAM (si flaquea):

AWS IAM Best Practices Whitepaper (gratis)
YouTube: "IAM Policy Examples" por Adrian Cantrill
Practica escribiendo policies complejas en AWS console

Para VPC (si flaquea):

YouTube: "VPC Deep Dive" - Cualquier creator serio
Dibuja 5 diagramas diferentes de VPC con diferentes grados de complejidad
Entiende la diferencia entre Security Groups y NACLs hasta el cansancio

Para Bases de Datos (si flaquea):

AWS Database Services Comparison Whitepaper
Lee estudios de caso reales en AWS blog
Entiende cuándo usar cada BD:
- SQL simple + relacionados = Aurora/RDS
- Key-value ultrarrápido = DynamoDB
- Analytics masivos = Redshift
- In-memory cache = ElastiCache
- Búsqueda de texto = Elasticsearch
- Timeseries = Timestream

Para Costos (si flaquea):

AWS Pricing Calculator (juega con ella)
Compara costos: On-Demand vs Reserved vs Spot
Lee publicaciones sobre Right-Sizing

Acción Concreta:

Haz 2-3 simulacros más (si aún no llegas a 80%)
Por cada pregunta fallida, anota:
- Qué me hizo fallar (falta de conocimiento vs mala lectura)
- Qué hubiera necesitado saber
Estudia específicamente ESO

Meta: Simular examen 5-6 con 80%+ de acierto.

🌐 Los Mejores Sitios Para Estudiar (Análisis Completo)

Aquí va el listado honesto:

Plataformas de Video (Teoría)

Plataforma	Precio	Calidad	Mejor Para	Contra
Coursera - AWS Fundamentals	$39/mes	⭐⭐⭐⭐⭐	Principiantes absolutos, bases sólidas	Lento al inicio
Adrian Cantrill (Udemy)	$15	⭐⭐⭐⭐⭐	Profundidad extrema, arquitectura	Muy largo (40+ horas)
A Cloud Guru/Pluralsight	$29/mes	⭐⭐⭐⭐	Práctico + teoría, labs	Debe renovar cada mes
Linux Academy	$29/mes	⭐⭐⭐⭐	Videos + documentación	Competencia fuerte
Udemy - Stephen Maarek	$15	⭐⭐⭐⭐	Paso a paso, bien organizado	Menos profundo que Cantrill
YouTube (Gratis)	Gratis	⭐⭐⭐	Complemento, videos específicos	Desorganizado, variable
AWS Official Training	$300+	⭐⭐⭐⭐	Certificado oficial, labs	Caro

Mi recomendación: Combina Coursera (fundamentos) + Adrian Cantrill (profundidad) + A Cloud Guru (labs prácticos).

Plataformas de Simulacros (Lo Más Importante)

Plataforma	Preguntas	Precio	Precisión	Mejor Para
Jon Bonso (Udemy)	780 (6 exámenes)	$15	⭐⭐⭐⭐⭐ Exacta	MEJOR OPCIÓN - Más cercano al real
Tutorial Dojo	1100+	$15	⭐⭐⭐⭐⭐ Excelente	Volumen, muy detallado
ExamPro	300+ (gratis)	Freemium	⭐⭐⭐⭐	Empezar gratis, buena base
AWS Sample Exam	40	Gratis	⭐⭐⭐⭐⭐ Oficial	Pequeño pero oficial
MeasureUp	400	$99	⭐⭐⭐⭐	Premium, menos conocido
Whizlabs	400+	$15	⭐⭐⭐	Barato, calidad media
DataCamp	Limitadas	$30/mes	⭐⭐⭐	Menos enfocado en Solutions Architect

Mi recomendación: Jon Bonso es IMPRESCINDIBLE. Si tienes presupuesto, agrega Tutorial Dojo. ExamPro free como complemento.

Whitepapers & Documentación (La Biblia)

Estos son gratis en AWS y son ORO:

AWS Well-Architected Framework - El más importante
- URL: aws.amazon.com/architecture/well-architected
- Lee completo: 1-2 horas
- Los 5 pilares son base de muchas preguntas
AWS Security Best Practices
- URL: aws.amazon.com/security/security-best-practices
- Enfocado en security: IAM, encryption, VPC
AWS Disaster Recovery
- URL: aws.amazon.com/disaster-recovery
- RTO, RPO, 4 strategies
Architecting on AWS (PDF whitepaper)
- Descargable directamente
- Casos de uso reales
AWS Database Services Comparison
- Cuándo usar qué BD
AWS Cost Optimization whitepaper
- Right-sizing, Reserved Instances, etc.

Cómo leerlos: No leas linealmente. Escanea, encuentra las secciones relevantes, profundiza.

Comunidades & Foros

Reddit - r/AWSCertifications
- Comunidad activa, preguntas diarias
- Gente pasando el examen ahora mismo
AWS Developer Forums
- Oficial, pero menos para certificación
LinuxAcademy Community
- Activa, gente preparándose
Discord Communities
- Búsca "AWS Certification Discord" - hay varios
- Gente estudiando en vivo, puedes hacer grupo de estudio

Consejo: No te pierdes en comunidades. 30 min/día máximo. No es productivo.

Herramientas Auxiliares

AWS Pricing Calculator (gratuita)
- Juega con diferentes configuraciones
- Entiende el pricing de verdad
AWS Architecture Icons (gratis)
- Descarga los iconos oficiales
- Dibuja tus propios diagramas
CloudCraft ($9/mes)
- Herramienta visual para diagramas
- Muy intuitiva
Lucidchart ($15/mes)
- Alternativa más profesional
Figma (gratis + pago)
- Puedes hacer diagramas también

⚠️ Los Errores Que Cometes (Y Cómo No Cometerlos)

Basado en miles de personas que intentaron esto:

Error #1: Memorizar Sin Entender

Síntoma: "Sé que el answer es X, pero no sé por qué."

El Problema: Vas a fallar cuando el examen pregunta algo similar pero no idéntico.

La Solución: Cuando estudies, siempre pregúntate "¿Por qué?" Mínimo 3 veces.

¿Por qué elegir Aurora en lugar de RDS?
Porque Aurora es más rápido y escalable.
¿Por qué es más rápido?
Porque el storage está separado de la computación.
¿Qué significa eso en práctica?
Significa que puedes escalar reads sin afectar writes.

Error #2: No Hacer Suficientes Simulacros

Síntoma: "He visto muchos videos pero me asusta hacer el examen real."

El Problema: Los simulacros no son castigo, son entrenamiento. Necesitas 5-6 mínimo.

La Solución: Haz simulacros incluso si tienes 70%. El objetivo es ver patrones y ganar velocidad.

Error #3: No Revisar Respuestas Incorrectas

Síntoma: "Sacaba 65% en los simulacros pero no mejoraba."

El Problema: Estabas repitiendo los mismos errores.

La Solución: De cada pregunta fallida, anota:

Qué me hizo fallar (falta de conocimiento, mala lectura, stress)
Qué debería haber sabido
Estudia ESO específicamente

Error #4: Enfocarse en Servicios "Cool" Que No Importan

Síntoma: "He estudiado a fondo Kinesis, SageMaker y AppSync."

El Problema: Eso es 2% del examen si acaso.

La Solución: Enfócate en los 25-30 servicios del 95% del examen.

Error #5: No Entender los Trade-offs

Síntoma: Ves dos opciones y no sabes elegir.

El Problema: AWS SIEMPRE tiene trade-offs. Nada es perfecto.

La Solución: Piensa en 3 dimensiones:

Costo: ¿Cuánto cuesta?
Rendimiento: ¿Qué tan rápido/escalable es?
Operacional: ¿Qué tan fácil es de manejar?

Ejemplo:

EC2 vs Lambda para procesar imágenes:
- EC2: Caro pero flexible, bueno si tienes spikes
- Lambda: Barato pero serverless, bueno si invocaciones son impredecibles
- Trade-off: El elegido depende de tu patrón de carga

Error #6: Perder Tiempo en Detalles Insignificantes

Síntoma: "Estudié a fondo las diferencias entre t3.micro y t3.small durante 2 horas."

El Problema: Eso no va a aparecer en el examen.

La Solución: Enfócate en decisiones arquitectónicas grandes:

¿EC2 o Lambda?
¿RDS o DynamoDB?
¿Multi-AZ o Multi-Región?

🎯 Mi Rutina De Estudio (Día a Día)

Para que veas exactamente qué hice:

Semana 1 (Fundamentos)

Lunes:

Mañana: Video Coursera AWS Fundamentals - Compute (2 horas)
Tarde: Notas + Dibuja diagrama EC2, tipos de instancias
Noche: Revisa que entendiste

Martes:

Mañana: Video Coursera - Storage (2 horas)
Tarde: Notas + S3 vs EBS vs EFS - cuadro comparativo
Noche: Duerme bien

Miércoles:

Mañana: Video Coursera - Database (3 horas, es más complejo)
Tarde: Notas + Cuándo usar cada BD
Noche: Revisa conceptos de días previos

Jueves:

Mañana: Video Coursera - Networking (2.5 horas)
Tarde: Dibuja una VPC completa con subnets, security groups, NAT
Noche: Duerme bien

Viernes:

Mañana: Video Adrian Cantrill - IAM Deep Dive (3 horas)
Tarde: Notas + Escribir policies de IAM en AWS console
Noche: Revisa los 5 conceptos de la semana

Sábado:

Descansa o repasa ligeramente

Domingo:

Repaso de toda la semana (2 horas)
Plan para la próxima semana

Semana 2 (Profundidad)

Misma estructura pero:

Menos video (max 2 horas/día)
Más práctica en AWS sandbox
Haz 2-3 labs por semana

Semana 3 (Simulacros)

Lunes: Simulacro 1 completo (2 horas) + análisis (2 horas)
Martes-Miércoles: Estudia áreas débiles
Jueves: Simulacro 2 + análisis
Viernes: Estudia áreas débiles
Sábado: Simulacro 3
Domingo: Análisis general

Semana 4 (Especialización)

Enfócate en lo que flaqueas:
Si IAM fue débil: 1 hora/día en IAM
Si VPC fue débil: 1 hora/día en VPC
Simulacro 4 en el medio de la semana
Simulacro 5 el viernes o sábado

📋 Checklist Pre-Examen (Una Semana Antes)

[ ] He hecho 5 simulacros completos
[ ] Mi puntuación promedio es 75%+
[ ] Entiendo los 5 pilares de Well-Architected
[ ] Puedo explicar cuándo usar S3 vs EBS vs EFS
[ ] Puedo explicar cuándo usar RDS vs DynamoDB
[ ] Entiendo IAM policies y trust relationships
[ ] Puedo dibujar una VPC con bastion, NAT, públicas y privadas
[ ] Entiendo Auto Scaling groups, load balancers, health checks
[ ] Sé qué es RTO/RPO y las 4 estrategias de DR
[ ] Entiendo trade-offs costo vs rendimiento vs seguridad
[ ] He revisado todas mis preguntas fallidas
[ ] Dormí 7-8 horas en los 3 días antes del examen

💪 Día del Examen: Estrategia Que Funciona

Antes

Duerme 8 horas (no "trabaja hasta las 4am para estudiar")
Come bien el desayuno
Llega 15 min antes
Usa el baño ANTES de entrar

Durante

Primeros 5 minutos: Lee lentamente, sin presión
Lectura de preguntas: Lee UNA VEZ lentamente. Mejor una lectura completa que dos apresuradas.
Strategy:
- Si sabes la respuesta → marca y sigue
- Si estás 80% seguro → marca y sigue
- Si no sabes → marca la que más sentido tiene, sigue, y vuelves al final
Timing: No dediques más de 3 minutos a una pregunta
Revisión: Si terminas con 10 minutos, revisa las que "marcaste como dudosa"

Después

No pienses en ello hasta que salga el resultado (48 horas)
La ansiedad es normal
La mayoría que siente que "salió mal" termina pasando

🚀 Después de Pasar: ¿Qué Sigue?

Una vez que hayas pasado:

Actualiza LinkedIn (mencionarlo ayuda a oportunidades)
Comparte tu experiencia (construye tu personal brand)
Continúa aprendiendo (el examen es inicio, no fin)
Considera AWS Solutions Architect Professional (si quieres más)
Aplica lo aprendido en tu trabajo o lado

El certificado es bonito, pero la verdadera ganancia es aprender a pensar como arquitecto.

📝 Preguntas Que Seguramente Tienes

P: ¿Puedo pasar sin experiencia previa en AWS?
R: Sí, pero necesitas 6-8 semanas de estudio disciplinado. No es imposible.

P: ¿Es necesario pagar los cursos premium o el contenido gratis es suficiente?
R: Honestamente, si combinas YouTube + AWS Whitepapers + Jon Bonso ($15), tienes 90% de lo que necesitas. Los cursos premium aceleran, no son obligatorios.

P: ¿Qué hago si tengo solo 3 semanas?
R: Es apretado. Enfócate en los 25-30 servicios principales, haz 4 simulacros, y dedica máximo 2-3 horas/día de estudio + 1 hora/día de práctica. Posible pero riesgoso.

P: ¿El examen es en inglés?
R: Sí, solo en inglés. Si no es tu lengua materna, practica leyendo preguntas en inglés.

P: ¿Cuánto tiempo es válido el certificado?
R: 3 años. Luego necesitas renovar.

P: ¿Vale la pena vs otras certificaciones?
R: AWS Solutions Architect es UNA DE las más reconocidas en la industria. Si trabajas con AWS, definitivamente vale.

🎬 Conclusión: La Verdad Sin Filtros

Este examen no es fácil, pero tampoco es imposible.

La diferencia entre los que pasan y los que no:

No es inteligencia: Gente brillante falla por mal preparación
No es suerte: Es disciplina y método
No es memorización: Es comprensión y criterio

Lo que SÍ importa:

Método estructurado (no estudiar al azar)
Práctica en simulacros (al menos 5)
Entender trade-offs (no solo memorizar)
Dormir bien (en serio, importa)

Si llegas a 75%+ consistente en simulacros, tienes 80%+ de probabilidad de pasar el examen real.

Mi consejo final: No pienses en "¿Logro pasar?" Piensa en "¿Quiero realmente aprender esto?"

Cuando cambias la pregunta, el camino se hace mucho más fácil.

Vas a poder. Dale.

¿Dudas? Comentá abajo y hablamos. Estoy acá para resolver lo que sea. ¿Alguien más está preparándose ahora? Vayan con todo. 💪

Hooks en Kiro: cómo automatizar tareas repetitivas con triggers inteligentes

Antonia Navarrete — Fri, 08 May 2026 05:35:34 +0000

Hooks en Kiro: cómo automatizar tareas repetitivas con triggers inteligentes

¿Cuántas veces al día le pides al agente que revise el linting, que genere tests o que actualice la documentación? Si la respuesta es "muchas", los agent hooks de Kiro son para ti. En lugar de repetir esas solicitudes manualmente, configuras una regla una sola vez y Kiro se encarga del resto, de forma automática y consistente.

En este post vamos a recorrer qué son los hooks, cómo funcionan, qué tipos de triggers tienes disponibles y cómo crear los tuyos desde cero.

¿Qué son los agent hooks?

Los agent hooks son disparadores automáticos que ejecutan una acción predefinida —ya sea un prompt al agente o un comando de shell— cuando ocurre un evento específico en tu IDE.

El sistema funciona en dos pasos:

Detección del evento: Kiro monitorea constantemente eventos como guardar un archivo, terminar una tarea o invocar una herramienta.
Ejecución de la acción: Cuando el evento ocurre, se dispara automáticamente la acción configurada.

Esto transforma la forma en que trabajas. Con hooks bien configurados puedes:

Mantener calidad de código consistente sin esfuerzo manual
Prevenir vulnerabilidades de seguridad desde el momento en que escribes
Reducir la carga cognitiva del equipo
Estandarizar procesos sin depender de que cada persona los recuerde
Crear ciclos de desarrollo más rápidos y predecibles

Los dos tipos de acción

Antes de ver los triggers, es importante entender qué puede hacer un hook cuando se dispara. Hay dos tipos de acción:

Agent Prompt (Ask Kiro)

Defines un prompt en lenguaje natural que se envía al agente cada vez que el hook se activa. El agente responde y actúa sobre él igual que lo haría con cualquier mensaje en el panel de chat. Es la opción correcta cuando la tarea depende del contexto actual del código.

Nota: Las acciones de tipo Agent Prompt consumen créditos, ya que inician un nuevo ciclo del agente.

Shell Command (Run Command)

Defines un comando de shell que se ejecuta localmente en tu máquina. Si el comando termina con exit code 0, su salida (stdout) se agrega al contexto del agente. Si falla, el error (stderr) se envía al agente como notificación. En los triggers Pre Tool Use y Prompt Submit, un fallo también bloquea la operación.

Los Shell Commands son más rápidos (se ejecutan localmente, sin LLM) y no consumen créditos. Son la opción correcta para tareas determinísticas que no dependen del contexto del agente.

Los 10 tipos de trigger disponibles

Kiro ofrece una variedad de triggers para cubrir prácticamente cualquier momento del ciclo de desarrollo.

Prompt Submit

Se activa cuando el usuario envía un prompt al agente. En modo Shell Command, el contenido del prompt es accesible mediante la variable de entorno USER_PROMPT.

Casos de uso:

Agregar contexto adicional relevante al prompt
Bloquear ciertos tipos de solicitudes según su contenido
Registrar todos los prompts en una ubicación central

Agent Stop

Se dispara cuando el agente ha completado su turno y terminó de responder.

Casos de uso:

Compilar el código generado y reportar fallos al agente
Formatear o revisar el código producido por el agente
Revisar los cambios realizados y dar instrucciones adicionales

Pre Tool Use

Se ejecuta justo antes de que el agente invoque una herramienta. En el campo Tool name puedes especificar herramientas concretas o usar categorías predefinidas:

Categoría	Descripción
`read`	Todas las herramientas de lectura de archivos
`write`	Todas las herramientas de escritura de archivos
`shell`	Todas las herramientas relacionadas con comandos de shell
`web`	Todas las herramientas web
`spec`	Todas las herramientas de spec
`*`	Todas las herramientas (built-in y MCP)

También puedes usar prefijos como @mcp, @powers o @builtin para filtrar por origen, e incluso patrones regex como @mcp.*sql.* para herramientas MCP específicas.

Casos de uso:

Bloquear invocaciones de herramientas no autorizadas
Agregar instrucciones adicionales antes de que el agente actúe

Post Tool Use

Se activa después de que el agente invoca una herramienta. Aplica la misma lógica de filtrado que Pre Tool Use.

Casos de uso:

Registrar invocaciones para auditoría
Formatear archivos actualizados después de una escritura
Dar instrucciones adicionales sobre el resultado de la herramienta

File Create

Se dispara cuando se crean archivos nuevos que coinciden con un patrón específico en tu workspace.

Casos de uso:

Generar boilerplate automáticamente para nuevos componentes
Agregar headers de licencia a archivos nuevos
Crear archivos de test en paralelo al crear archivos de implementación

File Save

Se activa cada vez que guardas un archivo que coincide con el patrón configurado. Es el trigger más usado en el día a día.

Casos de uso:

Ejecutar linting y formateo automático
Actualizar archivos relacionados
Generar o actualizar documentación
Correr tests para los archivos modificados

File Delete

Se dispara al eliminar archivos que coinciden con el patrón.

Casos de uso:

Limpiar archivos relacionados automáticamente
Actualizar referencias de imports en otros archivos
Mantener la integridad del proyecto

Pre Task Execution

Se ejecuta antes de que una tarea de spec comience su ejecución (cuando su estado cambia a in_progress).

Casos de uso:

Correr scripts de preparación o configuración del entorno
Validar que los prerequisitos estén cumplidos antes de iniciar
Registrar el inicio de la tarea para tracking

Post Task Execution

Se activa cuando una tarea de spec completa su ejecución (cuando su estado cambia a completed).

Casos de uso:

Correr tests para verificar la corrección de la tarea
Aplicar linting o formateo sobre los archivos modificados
Generar documentación del trabajo completado
Notificar sistemas externos sobre la finalización

Manual Trigger

Se ejecuta a demanda, cuando tú lo decides, mediante un clic en el panel de Kiro.

Casos de uso:

Code reviews puntuales
Generación de documentación bajo pedido
Escaneos de seguridad
Optimización de performance

Tres casos de uso reales

1. Sincronización automática de traducciones

Trigger: File Save | Archivos: locales/en.json

Cada vez que guardas el archivo de traducciones en inglés, el hook detecta qué claves se añadieron o modificaron, revisa todos los demás archivos de idioma, marca las claves ausentes con NEEDS_TRANSLATION y las modificadas con NEEDS_REVIEW, y genera un resumen de los cambios pendientes. El equipo de localización siempre sabe exactamente qué falta.

Instrucciones al agente:
1. Identify which string keys were added or modified
2. Check all other language files for these keys
3. For missing keys, add them with a "NEEDS_TRANSLATION" marker
4. For modified keys, mark them as "NEEDS_REVIEW"
5. Generate a summary of changes needed across all languages

2. Mantenedor de cobertura de tests

Trigger: File Save | Archivos: src/**/*.{js,ts,jsx,tsx}

Al modificar cualquier archivo fuente, el agente identifica las funciones nuevas o cambiadas, verifica si existen tests correspondientes, genera casos de prueba para el código sin cobertura, los ejecuta y actualiza los reportes. La cobertura de tests nunca cae.

Instrucciones al agente:
1. Identify new or modified functions and methods
2. Check if corresponding tests exist and cover the changes
3. If coverage is missing, generate test cases for the new code
4. Run the tests to verify they pass
5. Update coverage reports

3. Generador de documentación bajo demanda

Trigger: Manual Trigger

Con un clic, el agente genera documentación completa del archivo actual: extrae firmas de funciones y clases, documenta parámetros y tipos de retorno, incluye ejemplos de uso basados en el código existente, actualiza el README.md con los nuevos exports y verifica que todo siga los estándares del proyecto.

Instrucciones al agente:
1. Extract function and class signatures
2. Document parameters and return types
3. Provide usage examples based on existing code
4. Update the README.md with any new exports
5. Ensure documentation follows project standards

Cómo crear tu primer hook

Puedes crear hooks de dos maneras desde la sección Agent Hooks del panel de Kiro.

Opción A: con lenguaje natural (recomendado para empezar)

Navega a la sección Agent Hooks en el panel de Kiro
Haz clic en el botón +
Selecciona Ask Kiro to create a hook
Describe en lenguaje natural lo que quieres que haga el hook
Presiona Enter o haz clic en Submit
Revisa la configuración generada, ajusta si es necesario y haz clic en Save Hook

Opción B: configuración manual

Navega a la sección Agent Hooks en el panel de Kiro
Haz clic en el botón +
Selecciona Manually create a hook
Completa los campos del formulario:
- Title: nombre corto del hook
- Description: qué hace el hook
- Event: tipo de trigger (File Save, Post Tool Use, Pre Task Execution, etc.)
- Tool name: para hooks Pre/Post Tool Use, qué herramientas aplican
- File pattern: para hooks de archivo, qué archivos monitorear
- Action: Ask Kiro (prompt al agente) o Run Command (shell)
- Instructions / Command: el prompt o comando a ejecutar
Haz clic en Create Hook

Atajo útil: También puedes abrir el Hook UI desde el Command Palette con Cmd+Shift+P (Mac) o Ctrl+Shift+P (Windows/Linux) y escribiendo Kiro: Open Kiro Hook UI.

Gestión de hooks

Todos tus hooks están accesibles desde la sección Agent Hooks del panel de Kiro.

Activar / desactivar: Haz clic en el ícono de ojo junto al hook, o usa el switch Hook Enabled en la vista de detalle. No necesitas eliminar un hook para pausarlo.
Editar: Selecciona el hook y modifica cualquier campo. Los cambios aplican de inmediato.
Eliminar: Selecciona el hook, haz clic en Delete Hook y confirma. Esta acción no se puede deshacer.
Ejecutar manualmente: Para hooks de tipo Manual Trigger, usa el botón ▷ junto al nombre o el botón Start Hook en la vista de detalle.

Buenas prácticas

Diseño de hooks

Un hook, una responsabilidad. Enfoca cada hook en una sola tarea. Son más predecibles y fáciles de depurar.
Instrucciones claras y sin ambigüedad. Cuando uses Agent Prompt, escribe pasos numerados para operaciones complejas.
Empieza con alcance limitado. Para hooks de archivo, comienza con patrones restrictivos antes de ampliarlos.
Prueba con casos límite. Verifica que el hook maneje contenido inesperado o malformado sin fallar.

Rendimiento

Considera la frecuencia del trigger: hooks que se disparan muy seguido en archivos grandes pueden impactar tu flujo.
Usa patrones de archivo precisos para evitar ejecuciones innecesarias.
Para tareas determinísticas, prefiere Shell Command sobre Agent Prompt: es más rápido y no consume créditos.

Trabajo en equipo

Guarda las configuraciones de hooks en control de versiones para compartirlas con todo el equipo.
Documenta el propósito de cada hook y sus limitaciones conocidas.
Revisa y actualiza los hooks a medida que el proyecto evoluciona.
Elimina hooks que ya no sean necesarios para mantener el flujo limpio.

Hooks + MCP: el siguiente nivel

Los agent hooks se potencian aún más cuando se combinan con servidores MCP (Model Context Protocol). Al integrar MCP, los hooks pueden acceder a herramientas externas y APIs especializadas durante su ejecución.

Algunos ejemplos de lo que puedes lograr:

Verificar que el código respete el design system de Figma al guardar archivos CSS o HTML
Actualizar el estado de tickets en Jira o Asana cuando una tarea de spec se completa
Sincronizar una base de datos a partir de archivos de muestra en el proyecto

Para usarlos, configura los servidores MCP en Kiro y referencia sus herramientas directamente en las instrucciones del hook.

Próximos pasos

Los agent hooks son una de las funcionalidades más poderosas de Kiro para eliminar trabajo repetitivo del día a día. La clave está en identificar qué tareas haces manualmente con más frecuencia y automatizarlas una a una.

Un buen punto de partida: agrega un hook de File Save sobre tus archivos fuente principales con linting automático. Con eso solo ya notarás la diferencia.

[Boost]

Antonia Navarrete — Tue, 28 Apr 2026 21:20:28 +0000

Antonia Navarrete

Apr 28

Kiro Specs: Deja de Improvisar y Empieza a Planificar Features con IA

#ai #beginners #kiro #tutorial

5 min read

Kiro Specs: Deja de Improvisar y Empieza a Planificar Features con IA

Antonia Navarrete — Tue, 28 Apr 2026 21:15:37 +0000

Si alguna vez arrancaste a codear una feature "porque ya sabes lo que hay que hacer" y terminaste reescribiendo todo a mitad del camino... este post es para ti.

Kiro Specs es una de las funcionalidades más poderosas del IDE Kiro, y la mayoría de los devs la ignora porque suena a burocracia. Spoiler: no lo es. Es la diferencia entre vibe coding y desarrollo estructurado con IA.

¿Qué es un Spec en Kiro?

Un Spec (especificación) es un artefacto estructurado que convierte una idea de alto nivel en un plan de implementación detallado, con trazabilidad desde el requisito hasta el código.

Cada vez que creas un Spec, Kiro genera automáticamente tres archivos:

.kiro/specs/mi-feature/
├── requirements.md   → Qué debe hacer el sistema
├── design.md         → Cómo lo va a hacer
└── tasks.md          → Lista de tareas ejecutables

No son documentos para guardar en un cajón. Son artefactos vivos que la IA usa para generar código coherente y trazable.

Los Dos Workflows: ¿Por Dónde Empiezas?

Kiro ofrece dos flujos según tu punto de partida:

🔹 Requirements-First (Requisitos primero)

El flujo más común. Lo usas cuando sabes qué quieres construir pero el cómo es flexible.

Requisitos → Diseño → Tareas → Código

Cuándo usarlo:

Estás construyendo una feature desde cero
El producto manda (customer feedback, historias de usuario)
La arquitectura puede adaptarse a los requisitos
Proyecto greenfield

🔹 Design-First (Diseño primero)

Lo usas cuando ya tienes una arquitectura en mente o restricciones técnicas no negociables.

Diseño → Requisitos → Tareas → Código

Cuándo usarlo:

Tienes un diagrama de arquitectura existente
Hay requisitos no funcionales estrictos (latencia, compliance)
Estás portando diseños desde otra herramienta
Necesitas validar factibilidad técnica antes de comprometerte

La Notación EARS: Requisitos que la IA Entiende (y tú también)

El requirements.md usa EARS (Easy Approach to Requirements Syntax), un estándar de la industria para escribir requisitos sin ambigüedad.

El patrón es simple:

WHEN [condición o evento]
THE SYSTEM SHALL [comportamiento esperado]

Ejemplo: Sistema de autenticación

## Requisito 1: Registro de usuario
WHEN a user submits the registration form with valid email and password
THE SYSTEM SHALL create a new account and send a verification email

## Requisito 2: Validación de formulario
WHEN a user submits the registration form with an already-registered email
THE SYSTEM SHALL display an error message without creating a duplicate account

## Requisito 3: Bloqueo por intentos fallidos
WHEN a user fails to login 5 consecutive times
THE SYSTEM SHALL temporarily block the account for 15 minutes and notify the user

¿Por qué esto importa? Porque cada requisito en formato EARS es:

Inequívoco: no hay lugar para interpretaciones
Testeable: cada uno se convierte directamente en un caso de prueba
Trazable: puedes rastrear cada línea de código hasta el requisito que la originó

El design.md: Arquitectura Generada Automáticamente

Una vez confirmados los requisitos, Kiro genera el design.md con:

Arquitectura del sistema y sus componentes
Diagramas de secuencia
Modelos de datos e interfaces
Stack tecnológico recomendado
Estrategia de manejo de errores
Enfoque de testing

Fragmento de ejemplo:

## Arquitectura del Sistema de Autenticación

### Componentes
- **AuthController**: Maneja las rutas HTTP de autenticación
- **UserService**: Lógica de negocio para gestión de usuarios
- **TokenService**: Generación y validación de JWT
- **EmailService**: Envío de correos transaccionales

### Diagrama de Secuencia: Login

User → AuthController: POST /auth/login
AuthController → UserService: validateCredentials(email, password)
UserService → DB: findUserByEmail(email)
DB → UserService: user record
UserService → UserService: comparePassword(hash)
UserService → TokenService: generateJWT(userId)
TokenService → AuthController: { accessToken, refreshToken }
AuthController → User: 200 OK + tokens

El tasks.md: Tu Roadmap de Implementación

El último archivo que genera Kiro es el más concreto: una lista de tareas ejecutables, con dependencias y estado en tiempo real.

## Tareas de Implementación

- [ ] 1. Configurar la base de datos de usuarios
  - Crear migración para tabla `users`
  - Definir índices para email (unique)
  - Agregar campos: id, email, password_hash, created_at, is_verified

- [ ] 2. Implementar UserService
  - Método `createUser(email, password)`
  - Método `validateCredentials(email, password)`
  - Manejo de errores: DuplicateEmailError, InvalidCredentialsError

- [ ] 3. Implementar TokenService  
  - Generación de JWT con expiración configurable
  - Refresh token con rotación automática
  - Blacklist para tokens revocados

- [ ] 4. Crear AuthController
  - POST /auth/register
  - POST /auth/login
  - POST /auth/logout
  - POST /auth/refresh

- [ ] 5. Tests de integración
  - Happy path: registro → verificación → login
  - Error cases: email duplicado, credenciales inválidas
  - Rate limiting: 5 intentos fallidos → bloqueo

Puedes ejecutar cada tarea individualmente o todas a la vez. Kiro actualiza el estado en tiempo real mientras implementa.

Flujo Completo: Del Prompt al Código

Así se ve el proceso desde cero:

Paso 1: Crear el Spec

En el panel de Kiro, haz clic en + bajo la sección Specs, o escribe en el chat:

Spec: sistema de autenticación con registro por email,
login, logout y reset de contraseña. Debe proteger
contra fuerza bruta y validar formatos de email.

Paso 2: Elegir el workflow

Kiro te pregunta: ¿Feature o Bug fix? Selecciona Feature, luego elige Requirements-First.

Paso 3: Iterar sobre requisitos

Kiro genera el primer borrador de requirements.md. Puedes refinarlo:

Agrega un requisito para que el sistema soporte 
autenticación con Google OAuth como alternativa

Paso 4: Revisar el diseño

Kiro genera design.md. Aquí validas que la arquitectura sea correcta antes de que empiece a generar código. Puedes pedir cambios:

Cambia el storage de sesiones de memoria a Redis
para soportar múltiples instancias del servidor

Paso 5: Ejecutar tareas

Una vez aprobado el diseño, abres tasks.md y ejecutas las tareas. Kiro implementa, y tú revisas.

Cuándo Usar Specs vs. Vibe Coding

No siempre necesitas un Spec. Aquí la guía rápida:

Situación	Usa
Feature compleja con múltiples componentes	Specs
Bug donde las regresiones son costosas	Specs
Necesitas documentación para el equipo	Specs
Prototipo rápido sin objetivos claros	Vibe
Exploración técnica sin entregables	Vibe
Cambio menor de una sola línea	Vibe

Tips para Sacarle el Máximo

1. Itera en los requisitos ANTES de pasar al diseño. El poder de Requirements-First está en definir bien el "qué" antes de comprometerte con el "cómo".

2. Importa requisitos existentes. Si tienes un PRD en Confluence o tickets en Jira, puedes copiar el contenido a un archivo y pedirle a Kiro que genere el Spec desde él:

#mi-prd.md Genera un spec a partir de este documento

3. Usa imágenes de arquitectura. Si tienes un diagrama en draw.io o una foto de la pizarra, puedes incluirlo en tu prompt al usar Design-First. Kiro lo interpreta.

4. Los Specs son vivos. Si cambian los requisitos, no empieces de cero: edita requirements.md y haz clic en Refine en el design.md. Kiro actualiza todo en cascada.

Conclusión

Los Specs de Kiro no son burocracia: son la forma de hacer que la IA trabaje de manera predecible y trazable en features complejas. En lugar de tener un agente que improvisa, tienes uno que sigue un plan que tú aprobaste.

La próxima vez que vayas a arrancar una feature no trivial, antes de escribir la primera línea de código, prueba crear un Spec. El tiempo que "perdés" planificando te lo devuelve duplicado en debugging evitado.

¿Te resultó útil? En el próximo post voy a cubrir **Hooks: cómo automatizar tareas repetitivas con triggers inteligentes en Kiro.